fedora-atomic discussion point: /usr/lib/passwd

Simo Sorce simo at redhat.com
Wed Apr 30 03:23:21 UTC 2014

On Mon, 2014-04-28 at 18:50 +0000, Colin Walters wrote:
> On Mon, Apr 28, 2014 at 1:39 PM, Simo Sorce <simo at redhat.com> wrote:
> > 
> > We can do that with SSSD, which we are planning to take over all users
> > (though it will leave /etc/passwd on the system for emergency repair 
> > and
> > backward compatibility).
> Ok, though one thing that's going to be important to me at least is the 
> ability to mutate the user list "offline" - the use case here is 
> something like an installer where you're operating on a different 
> target root.  So in addition to the DBus API, there would need to be a 
> way to use a shared library API with a "const char *chroot" type 
> argument (as e.g. ostree_sysroot_new() has now).

can you use an actual chroot ?

> Ideally that ends up being dumb filesystem manipulation, maybe 
> invalidating some database-type caches that are then regenerated on 
> boot or so.  And I should be able to control whether or not fdatasync() 
> occurs on written files.  A bit more on the fdatasync() topic here: 
> http://marc.info/?l=selinux&m=139578267630878&w=2

I am not sure I understand the fdatasync() argument here ?
sssd uses a database, so it is indeed probably "heavy" on f(data)sync
for your standards (?).


Simo Sorce * Red Hat, Inc * New York

More information about the devel mailing list