[SSSD] [PATCH] Allow running with read only root

Stephen Gallagher sgallagh at redhat.com
Wed Mar 24 20:30:09 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/24/2010 10:38 AM, Jakub Hrozek wrote:
> On 03/24/2010 03:10 PM, Simo Sorce wrote:
>> On Wed, 24 Mar 2010 10:04:14 -0400
>> Simo Sorce <ssorce at redhat.com> wrote:
> 
>>> On Wed, 24 Mar 2010 14:51:07 +0100
>>> Jakub Hrozek <jhrozek at redhat.com> wrote:
>>>
>>>> Packages /etc/rwtab.d/sssd file that allows SSSD to run on a
>>>> read-only root filesystem.
>>>
>>> NACK.
>>>
>>> The way rwtab normally works is that it creates a tmpfs and symlinks
>>> or bind mounts it to the locations given by rwtab.
>>>
>>> But this means the data will be discarded at the first reboot.
>>>
>>> SSSD data is not just cache, sssd.ldb has to survive across reboots so
>>> this approach is wrong. True sssd will start and work, except you will
>>> loose everything on reboot.
>>>
>>> I do not want to endorse, make it easy or even recommend to create
>>> such a broken configuration.
>>>
>>> /var/lib has to be writable and not shared if you want to run some
>>> services, and if you want it read-only/shared/etc you better not use
>>> sssd.
> 
> 
>> Just to be clear, I am not saying we should actively prevent use of
>> sssd on stateless machines, but sssd by its very nature is not
>> stateless, so if an admin wants to use it in a stateless way he has to
>> make the choice consciously and explicitly and evaluate if it makes
>> sense or not.
> 
> 
> I agree with this. But I think that this explicit decision is made when
> the admin opts for stateless machines. And when he makes it, I think our
> software should just work - or the subset that makes sense on a
> stateless machine.
> 
> Even on a clean, pristine Fedora install, there is a file /etc/rwtab
> that contains many entries - some even specific to a certain package
> like /var/puppet. Unless you change your configuration to a ro root,
> these don't have any effect - and so does the file in this patch have no
> effect until the admin starts using ro root.
> 
>> sssd can still give some benefits as it can better cache some things
>> reducing load on an ldap server or as a showcase in a livecd, but will
>> also loose all the good stuff like being able to login offline after a
>> reboot.
> 
> 
> I don't think anyone expects that from a stateless client. Caching the
> NSS and PAM data between reboots is a win on its own.
> 
>> So given that sssd would loose a consitent set of its features on a
>> stateless machine we shouldn't make it work on there by default IMO.
> 
>> Simo.
> 


I agree with Jakub here. I think it's perfectly acceptable to include
the SSSD in the rwtab. A person using a read-only root is probably doing
so BECAUSE they don't care about persistence across reboots. In these
cases, having our SSSD as a cache while the machine is up is still
advantageous, because it allows the machine to survive a remote auth
server outage.

Yes, we'll lose the cache on reboot, and we will be unable to use SSSD
for a provider=local setup, but I very much doubt that anyone would be
using it for anything other than a reliable cache in this situation.


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuqdlEACgkQeiVVYja6o6Nf6ACgk0UTF/1DpUWRMMBrSoOTMyOY
NBsAmgM2xSryydKnylp3yEO9p2/CbJ0p
=5jRd
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list