Discussion:
fedora-atomic discussion point: /usr/lib/passwd
(too old to reply)
Colin Walters
2014-04-11 06:33:59 UTC
Permalink
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.

Patch is linked from my post here:
http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html

Also, some discussion in the glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=16142

What I'd like to open is a discussion about whether /usr/lib/passwd is
the right thing long term. I think it'd be very useful to support it
short term, but it's not perfect.

The main case where it breaks is when you have a daemon that runs as
non-root and saves state, so you give it its own system user, but not a
reserved uid. Daemons in this class will have their uids effectively
ordered by package installation order =/

One way to fix this that goes with my general direction of moving
things out of %post into systemd: a dynamic uid reservation system that
saves state persistently.

Crudely, this would be ExecStartPre=/usr/sbin/useradd -r ...
except we'd wrap that with something that checked whether the user
existed first.

Then /etc/passwd would still be local system-persistent state, and
OSTree still wouldn't need to run a %post. I think though it'd be good
to still use /usr/lib/passwd in this model for daemons that *don't*
save state persistently, like dbus. No need to pollute /etc/passwd
with them.

(Note, we'd also need to teach %systemd_preun to run some kind of
ExecUninstall=, or skip spawning subprocesses and teach systemd how to
modify the user database directly)

Thoughts?
Lennart Poettering
2014-04-11 14:34:06 UTC
Permalink
Post by Colin Walters
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html
https://sourceware.org/bugzilla/show_bug.cgi?id=16142
What I'd like to open is a discussion about whether /usr/lib/passwd
is the right thing long term. I think it'd be very useful to
support it short term, but it's not perfect.
I am really not convinced that this is a good idea and will really
fly. Having a fully static passwd file can't really work since admins
must have the ability to change certain user attributes for certain
system users. This is quite obvious for the root user, where the admin
must be able to set the password, but applies to a lot of other cases
too (for example, it is common practice to set passwords, shell, home
dir for database users, for example for setting up rsync-based backup
schemes, or to manipulate group membership for system users).

Hence I strongly doubt that immutable, vendor-supplied password files
can ever work. The goal here must be to declaratively *populate* the
initial password file from some vendor-supplied table, but not to
*equate* them, if you follow what I mean.

Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them. With that in place we can support schemes
where a "factory reset" of the system can be easily done by simply
flushing /etc and /var altogether and then repopulating it from this
data. THis is particularly useful in order to run 1000s of container
instances off the same /usr tree, where the instance-specific /etc and
/var is created as needed when the container first boots up. These "factory"
files would support pretty much two directives only: one to create
system users/groups with specific parameters (with the numeric UID/GID possibly
sourced off the stat() data of some other file in /usr, so that we can
support suid/sgid binaries nicely), and another one to copy files that
are strictly needed for boot into /etc).

Lennart
--
Lennart Poettering, Red Hat
"Jóhann B. Guðmundsson"
2014-04-11 14:41:48 UTC
Permalink
Post by Lennart Poettering
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them.
I dont think /etc the right place to be used here based on the evolution
taking place so suggest containers should source that from elsewhere.

JBG
Lennart Poettering
2014-04-11 14:47:27 UTC
Permalink
Post by "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them.
I dont think /etc the right place to be used here based on the
evolution taking place so suggest containers should source that from
elsewhere.
I cannot parse this?

Lennart
--
Lennart Poettering, Red Hat
"Jóhann B. Guðmundsson"
2014-04-11 15:05:38 UTC
Permalink
Post by Lennart Poettering
Post by "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them.
I dont think /etc the right place to be used here based on the
evolution taking place so suggest containers should source that from
elsewhere.
I cannot parse this?
/etc is "administrator space" and evolving into "administrator only
space" which means eventually nothing will be placing or flushing or
populating there other then the administrators themselves.

In other words if containers have to "populate" /etc they are doing it
wrong hence the overall design is wrong

JBG
drago01
2014-04-11 15:11:50 UTC
Permalink
On Fri, Apr 11, 2014 at 5:05 PM, "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Post by "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them.
I dont think /etc the right place to be used here based on the
evolution taking place so suggest containers should source that from
elsewhere.
I cannot parse this?
/etc is "administrator space" and evolving into "administrator only space"
which means eventually nothing will be placing or flushing or populating
there other then the administrators themselves.
In other words if containers have to "populate" /etc they are doing it wrong
hence the overall design is wrong
This thread is not about containers.
"Jóhann B. Guðmundsson"
2014-04-11 15:19:20 UTC
Permalink
Post by drago01
On Fri, Apr 11, 2014 at 5:05 PM, "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Post by "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them.
I dont think /etc the right place to be used here based on the
evolution taking place so suggest containers should source that from
elsewhere.
I cannot parse this?
/etc is "administrator space" and evolving into "administrator only space"
which means eventually nothing will be placing or flushing or populating
there other then the administrators themselves.
In other words if containers have to "populate" /etc they are doing it wrong
hence the overall design is wrong
This thread is not about containers.
And?

The outcome is the same as things are evolving *nothing* would be
adding,editing anything to /etc other then administrators themselves.


JBG
Lennart Poettering
2014-04-11 15:27:26 UTC
Permalink
Post by "Jóhann B. Guðmundsson"
Post by drago01
On Fri, Apr 11, 2014 at 5:05 PM, "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Post by "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them.
I dont think /etc the right place to be used here based on the
evolution taking place so suggest containers should source that from
elsewhere.
I cannot parse this?
/etc is "administrator space" and evolving into "administrator only space"
which means eventually nothing will be placing or flushing or populating
there other then the administrators themselves.
In other words if containers have to "populate" /etc they are doing it wrong
hence the overall design is wrong
This thread is not about containers.
And?
The outcome is the same as things are evolving *nothing* would be
adding,editing anything to /etc other then administrators
themselves.
For me the "factory" systemd stuff is actually very much about
containers. It's actually kinda my primary goal here: I want to allow
deployment of a single /usr in a thousnad containers, so that each
container's /etc and /var is automatically populated on boot, without
any manual interference of the admin.

The same scheme is also useful on embedded and desktop/tablet/phone
setups though where we really want a "factory reset" scheme, the same
way as Android has it.

Lennart
--
Lennart Poettering, Red Hat
"Jóhann B. Guðmundsson"
2014-04-11 16:05:31 UTC
Permalink
Post by Lennart Poettering
For me the "factory" systemd stuff is actually very much about
containers. It's actually kinda my primary goal here: I want to allow
deployment of a single /usr in a thousnad containers, so that each
container's /etc and /var is automatically populated on boot, without
any manual interference of the admin.
The problem here is /etc
Post by Lennart Poettering
The same scheme is also useful on embedded and desktop/tablet/phone
setups though where we really want a "factory reset" scheme, the same
way as Android has it.
Yes but you seem to be equalling system/application defaults and
system/application written overwrites or configuration changes to those
configuration changes and overwrites performed by the user/administrator
which is not the same thing, so while you could flush the
system/application default settings and application written overwrites
regardless if it's due to "factory reset" or due to them being upgrade
to a new release you cannot do so with user/administrator overwrites
because they want to retain their own settings after they flushed or
upgrade the device or container so an single directory that serves both
this purposes cannot exist and an new directory which clearly splits the
purpose both of these is bound to emerge as things evolve further.

JGB
Lennart Poettering
2014-04-11 15:22:47 UTC
Permalink
Post by "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Post by "Jóhann B. Guðmundsson"
Post by Lennart Poettering
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them.
I dont think /etc the right place to be used here based on the
evolution taking place so suggest containers should source that from
elsewhere.
I cannot parse this?
/etc is "administrator space" and evolving into "administrator only
space" which means eventually nothing will be placing or flushing or
populating there other then the administrators themselves.
In other words if containers have to "populate" /etc they are doing
it wrong hence the overall design is wrong
I wish it was that easy. It's not though.

During early boot /etc+/usr are available, but /var is not. System users
must be available during early boot (hence cannot be configured in
/var), and (as indicated earlier in this thread) must also be
manipulatable for the admin (hence cannot be configured in /usr). This
means they need to be stored in /etc, which pushes us towards having to
populate /etc when empty, rather than supporting entirely empty /etc
boots.

And it doesn't stop there. We have binary caches in /etc, like the
selinux policy, hwdb, ... which must be available during early boot but
also aren't so static and immutable that they could be located in
/usr. WHich also means that they need a regeneration step at boot.

Similar for /etc/machine-id, which is something we should always and
unconditionally provide, which needs to be regenerated when /etc is
flushed, and where we cannot support entirely empty /etc boots.

And then, there's the elephant in the room: it's unlikely we can fix
*all* Linux software to be fine with an empty /etc anytime soon. Sure,
systemd itself is carefully prepared to handle this correctly, but we
ship so much old cruft that noody wants to touch, that we need a softer
transition here, and thus need to prvide a way to populate /etc.

I mean, I fully agree that the populating logic should be minimal. We
really shouldn't push more stuff in /etc than really strictly necessary,
but I fear we really have to allow it for the strictly basic stuff, it's
unavoidable.

Lennart
--
Lennart Poettering, Red Hat
"Jóhann B. Guðmundsson"
2014-04-11 15:40:28 UTC
Permalink
Post by Lennart Poettering
Post by "Jóhann B. Guðmundsson"
/etc is "administrator space" and evolving into "administrator only
space" which means eventually nothing will be placing or flushing or
populating there other then the administrators themselves.
In other words if containers have to "populate" /etc they are doing
it wrong hence the overall design is wrong
I wish it was that easy. It's not though.
During early boot /etc+/usr are available, but /var is not. System users
must be available during early boot (hence cannot be configured in
/var), and (as indicated earlier in this thread) must also be
manipulatable for the admin (hence cannot be configured in /usr). This
means they need to be stored in /etc, which pushes us towards having to
populate /etc when empty, rather than supporting entirely empty /etc
boots.
And it doesn't stop there. We have binary caches in /etc, like the
selinux policy, hwdb, ... which must be available during early boot but
also aren't so static and immutable that they could be located in
/usr. WHich also means that they need a regeneration step at boot.
Similar for /etc/machine-id, which is something we should always and
unconditionally provide, which needs to be regenerated when /etc is
flushed, and where we cannot support entirely empty /etc boots.
And then, there's the elephant in the room: it's unlikely we can fix
*all* Linux software to be fine with an empty /etc anytime soon. Sure,
systemd itself is carefully prepared to handle this correctly, but we
ship so much old cruft that noody wants to touch, that we need a softer
transition here, and thus need to prvide a way to populate /etc.
I mean, I fully agree that the populating logic should be minimal. We
really shouldn't push more stuff in /etc than really strictly necessary,
but I fear we really have to allow it for the strictly basic stuff, it's
unavoidable.
Interesting I expected a new /foo directory to emerge which provided the
functionality you described and FSH be evolve accordingly as things
progressed further into this direction but based on what you say here
you are indicating that cannot happen as in /etc must be the directory
that provides this.

Is that the case or am I missing something?

JBG
Colin Walters
2014-04-11 15:49:51 UTC
Permalink
On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
Post by Lennart Poettering
I am really not convinced that this is a good idea and will really
fly. Having a fully static passwd file can't really work since admins
must have the ability to change certain user attributes for certain
system users. This is quite obvious for the root user,
root is in /etc/passwd. What this means in practice is that as soon as
another user is added, the client machine has a forked copy of
/etc/passwd, and will no longer receive any changes to root's entry
either. But it's not like we change it much.
Post by Lennart Poettering
where the admin
must be able to set the password, but applies to a lot of other cases
too (for example, it is common practice to set passwords, shell, home
dir for database users,
Yeah. But admins can copy the user data to /etc/passwd, and that wins.
That seems fine to me.
Post by Lennart Poettering
Hence I strongly doubt that immutable, vendor-supplied password files
can ever work. The goal here must be to declaratively *populate* the
initial password file from some vendor-supplied table, but not to
*equate* them, if you follow what I mean.
Hmm. Is there a reason you prefer that instead of an "equate but with
overrides" model?
Post by Lennart Poettering
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically at boot if systemd finds /etc and
/var empty to populate them.
The problem is that I need daemon users to be added (and removed) even
*after* system installation. This can occur when simply upgrading, or
when switching trees, or when adding packages on top of a base tree.
Post by Lennart Poettering
THis is particularly useful in order to run 1000s of container
instances off the same /usr tree,
If your container tree is immutable, then I can see that working, but
do you see supporting dynamic changes to the container content? If so
it's the exact same situation with ostree.

Now maybe with containers you don't care about atomic upgrades, and
furthermore while you're running arbitrary %post code as root, at least
it'd be in a container and not actually operating live on your root
filesystem.
Post by Lennart Poettering
These "factory"
files would support pretty much two directives only: one to create
system users/groups with specific parameters (with the numeric
UID/GID possibly
sourced off the stat() data of some other file in /usr, so that we can
support suid/sgid binaries nicely), and another one to copy files that
are strictly needed for boot into /etc).
Hmm...I'm going to reply to Martin on this point.
Lennart Poettering
2014-04-11 16:39:26 UTC
Permalink
Post by Colin Walters
On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
Post by Lennart Poettering
I am really not convinced that this is a good idea and will really
fly. Having a fully static passwd file can't really work since admins
must have the ability to change certain user attributes for certain
system users. This is quite obvious for the root user,
root is in /etc/passwd. What this means in practice is that as soon
as another user is added, the client machine has a forked copy of
/etc/passwd, and will no longer receive any changes to root's entry
either. But it's not like we change it much.
Would you copy the entire file from to /etc or just that one entry?

I can see why you would like to avoid the population step, but if we
want that, then let's go one step further: have a drop-in dir in /usr,
where packages can drop in new user definitions for system users, which
is then scanned by an NSS module. tools like "passwd" would then have
to be patched to be able to copy individual entries into /etc when they
shall be updated.

Now, this still leaves the question open what to do about system users
that do not have statically assigned numeric UIDs, in particular
everything 3rd party. If I understand you correctly, you want this to be
convered by systemd with a new service option that will allocate the uid
on first service start?

So how about this then, we have a drop-in dir in /usr as above, with
files that list the numeric UID where possible. For the cases where
that's not possible however, we'd check some additional db in /var. If
that db doesn't contain a numeric UID yet the lookup would fail. Then,
we'd add logic to systemd to possibly assign numeric UIDs to such users
when User= is specified for a service. In addition we'd add a new switch
AlocateUser= or so, which does the same thing for arbitrary users,
without implying the setresuid() bit that User= is for? Using
AllocateUser= would also imply RequiresMountsFor=/var/lib/userdb (for
the right path...).

Essentially this would mean we would allow dynamic UIDs only for
later-boot services (i.e. normal services), but not for early-boot
services, which sounds like a OK restriction to make to me.

With that in place the population of /etc/passwd would be unnecessary.

Did I get this right that this is would be inline with what you are
asking for? I am warming up to this.

Lennart
--
Lennart Poettering, Red Hat
Simo Sorce
2014-04-11 16:47:19 UTC
Permalink
Post by Lennart Poettering
Post by Colin Walters
On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
Post by Lennart Poettering
I am really not convinced that this is a good idea and will really
fly. Having a fully static passwd file can't really work since admins
must have the ability to change certain user attributes for certain
system users. This is quite obvious for the root user,
root is in /etc/passwd. What this means in practice is that as soon
as another user is added, the client machine has a forked copy of
/etc/passwd, and will no longer receive any changes to root's entry
either. But it's not like we change it much.
Would you copy the entire file from to /etc or just that one entry?
I can see why you would like to avoid the population step, but if we
want that, then let's go one step further: have a drop-in dir in /usr,
where packages can drop in new user definitions for system users, which
is then scanned by an NSS module. tools like "passwd" would then have
to be patched to be able to copy individual entries into /etc when they
shall be updated.
Now, this still leaves the question open what to do about system users
that do not have statically assigned numeric UIDs, in particular
everything 3rd party. If I understand you correctly, you want this to be
convered by systemd with a new service option that will allocate the uid
on first service start?
So how about this then, we have a drop-in dir in /usr as above, with
files that list the numeric UID where possible. For the cases where
that's not possible however, we'd check some additional db in /var. If
that db doesn't contain a numeric UID yet the lookup would fail. Then,
we'd add logic to systemd to possibly assign numeric UIDs to such users
when User= is specified for a service. In addition we'd add a new switch
AlocateUser= or so, which does the same thing for arbitrary users,
without implying the setresuid() bit that User= is for? Using
AllocateUser= would also imply RequiresMountsFor=/var/lib/userdb (for
the right path...).
This sounds extremely brittle, I can see people causing all sort of
issues releasing unit files that have AllocateUser by default.
Then when someone puts those users in a network database (ldap, nis,
etc), a conflict would be generated the first time the service is
started and the user is not found (because the server fell off the
network).

I think this scheme is baroque and prone to nasty failures in real
deployment. Please don't do that.
Post by Lennart Poettering
Essentially this would mean we would allow dynamic UIDs only for
later-boot services (i.e. normal services), but not for early-boot
services, which sounds like a OK restriction to make to me.
It is just a recipe for disaster, you are making the whole system
fragile in order to handle a corner case.
Post by Lennart Poettering
With that in place the population of /etc/passwd would be unnecessary.
Did I get this right that this is would be inline with what you are
asking for? I am warming up to this.
I think it is a *very* bad idea,

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Lennart Poettering
2014-04-11 17:01:26 UTC
Permalink
Post by Simo Sorce
Post by Lennart Poettering
So how about this then, we have a drop-in dir in /usr as above, with
files that list the numeric UID where possible. For the cases where
that's not possible however, we'd check some additional db in /var. If
that db doesn't contain a numeric UID yet the lookup would fail. Then,
we'd add logic to systemd to possibly assign numeric UIDs to such users
when User= is specified for a service. In addition we'd add a new switch
AlocateUser= or so, which does the same thing for arbitrary users,
without implying the setresuid() bit that User= is for? Using
AllocateUser= would also imply RequiresMountsFor=/var/lib/userdb (for
the right path...).
This sounds extremely brittle, I can see people causing all sort of
issues releasing unit files that have AllocateUser by default.
Then when someone puts those users in a network database (ldap, nis,
etc), a conflict would be generated the first time the service is
started and the user is not found (because the server fell off the
network).
This has come up before. But: system users must be resolvable locally,
always, and unconditionally. udev, tmpfiles, ... will all break if that
is not the case.

if you place system users in LDAP, then it's your own fault if things
break, and we should strictly not support that.

It's one thing to sync system users against LDAP, but storing them there
exclusively cannot work, and is currently not supported, and is
something we should not support.
Post by Simo Sorce
I think this scheme is baroque and prone to nasty failures in real
deployment. Please don't do that.
Nope. The baroque/error-prone bit is to place system users in LDAP,
everything else is just a corrollary of that...

Lennart
--
Lennart Poettering, Red Hat
Simo Sorce
2014-04-11 17:14:15 UTC
Permalink
Post by Lennart Poettering
Post by Simo Sorce
Post by Lennart Poettering
So how about this then, we have a drop-in dir in /usr as above, with
files that list the numeric UID where possible. For the cases where
that's not possible however, we'd check some additional db in /var. If
that db doesn't contain a numeric UID yet the lookup would fail. Then,
we'd add logic to systemd to possibly assign numeric UIDs to such users
when User= is specified for a service. In addition we'd add a new switch
AlocateUser= or so, which does the same thing for arbitrary users,
without implying the setresuid() bit that User= is for? Using
AllocateUser= would also imply RequiresMountsFor=/var/lib/userdb (for
the right path...).
This sounds extremely brittle, I can see people causing all sort of
issues releasing unit files that have AllocateUser by default.
Then when someone puts those users in a network database (ldap, nis,
etc), a conflict would be generated the first time the service is
started and the user is not found (because the server fell off the
network).
This has come up before. But: system users must be resolvable locally,
always, and unconditionally. udev, tmpfiles, ... will all break if that
is not the case.
This is true for *some* system users.
Post by Lennart Poettering
if you place system users in LDAP, then it's your own fault if things
break, and we should strictly not support that.
It is ok if my 'foo' database fails to start if the network is down.
It is *an entirely* different matter if the system creates a mismatching
(different uid/gid) user out of its ass when that happens.
Post by Lennart Poettering
It's one thing to sync system users against LDAP, but storing them there
exclusively cannot work, and is currently not supported, and is
something we should not support.
We do not need to support it as in "we guarantee your application will
always work", but it is unreasonable to build a system where "we
guarantee to screw you up" if a lookup ever fails for whatever reason.
Post by Lennart Poettering
Post by Simo Sorce
I think this scheme is baroque and prone to nasty failures in real
deployment. Please don't do that.
Nope. The baroque/error-prone bit is to place system users in LDAP,
everything else is just a corrollary of that...
This scheme is not fail safe, hence it is not a good scheme, that is
all.

I am sure we can find a better scheme that can achieve the result and
still is fail safe.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Martin Langhoff
2014-04-11 15:33:29 UTC
Permalink
One way to fix this that goes with my general direction of moving things out
of %post into systemd: a dynamic uid reservation system that saves state
persistently.
Crudely, this would be ExecStartPre=/usr/sbin/useradd -r ...
except we'd wrap that with something that checked whether the user existed
first.
If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.

This has quite broad implications.


m
--
martin.langhoff at gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
Colin Walters
2014-04-11 16:09:27 UTC
Permalink
On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
Post by Martin Langhoff
If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.
That's a really good point. I hadn't thought about that. Urgh. The
way this works in the RPM world is so evil - rpm calls out to
/usr/sbin/useradd which then modifies /etc/passwd, which rpm then
reloads and reads, to use as a source for calling chown() for files on
disk.

It theoretically avoids rpm knowing about nss, but in practice it's
just a very fragile plugin. If useradd fails for some reason (say
stale lock file), typically the %post have "|| :" to ignore errors so
the files end up owned by root...

This does make my plans to support package installation on top of a
base tree more complex as we really do need NSS in place during tree
construction. I'll think about this, but I suspect this may end with
ostree understanding the NSS configuration.
Simo Sorce
2014-04-11 16:23:38 UTC
Permalink
Post by Colin Walters
On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
Post by Martin Langhoff
If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.
That's a really good point. I hadn't thought about that. Urgh. The
way this works in the RPM world is so evil - rpm calls out to
/usr/sbin/useradd which then modifies /etc/passwd, which rpm then
reloads and reads, to use as a source for calling chown() for files on
disk.
It theoretically avoids rpm knowing about nss, but in practice it's
just a very fragile plugin. If useradd fails for some reason (say
stale lock file), typically the %post have "|| :" to ignore errors so
the files end up owned by root...
This does make my plans to support package installation on top of a
base tree more complex as we really do need NSS in place during tree
construction. I'll think about this, but I suspect this may end with
ostree understanding the NSS configuration.
Keep in mind accounts may not even be in /etc/passwd so you definitely
want to understand nsswitch.conf

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Lennart Poettering
2014-04-11 16:49:18 UTC
Permalink
Post by Colin Walters
On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
Post by Martin Langhoff
If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.
Hmm, let's think for a moment what kind of files this actually matters
for. In which directories do system users actually own files?

That'd be suid/sgid binaries in /usr/bin. That'd be working directories
in /run and /var. Anything else?

The latter don't sound too bad, since we can allocate them during late
boot. The fomer is the messy bit.

Maybe the cheap way out is to disallow suid/sgid binaries in /usr/bin
for dynamically assigned UIDs/GIDs. I this day and age, are there still
good usecases for that?

Lennart
--
Lennart Poettering, Red Hat
Stephen John Smoogen
2014-04-11 16:54:14 UTC
Permalink
Post by Lennart Poettering
Post by Colin Walters
On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
Post by Martin Langhoff
If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.
Hmm, let's think for a moment what kind of files this actually matters
for. In which directories do system users actually own files?
Aren't there 'helper' programs that sometimes live in /usr/lib/<something>
eg every program that expects /usr/libexec or something?

I would say that a full fedora install needs to be done and then see what
the cruft is so that it either can be 'fixed' for this or known and dealt
with.
--
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140411/efccf75a/attachment.html>
Martin Langhoff
2014-04-11 17:08:03 UTC
Permalink
On Fri, Apr 11, 2014 at 12:49 PM, Lennart Poettering
Post by Lennart Poettering
Post by Colin Walters
On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
Post by Martin Langhoff
If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.
Hmm, let's think for a moment what kind of files this actually matters
for. In which directories do system users actually own files?
That'd be suid/sgid binaries in /usr/bin. That'd be working directories
in /run and /var. Anything else?
The latter don't sound too bad, since we can allocate them during late
boot. The fomer is the messy bit.
Stuff like /var/lib/{mysql,ldap} is what I was mainly referring to.
The services depend or could/should depend on resolving any mounts
needed to get /var/lib in place.

Not a big deal for systemd, but I want to note -- the creation of
/var/lib/{svc} is often driven by a script that may do additional work
(i.e.: create a template database), and may have interesting error
conditions.

Not sure why you mention suid/sgid -- this applies as long as the
service is run as a particular user. Maybe systemd needs to resolve
those users while parsing the service files?




m
--
martin.langhoff at gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
Colin Walters
2014-04-12 05:24:43 UTC
Permalink
On Fri, Apr 11, 2014 at 12:09 PM, Colin Walters <walters at verbum.org>
Post by Colin Walters
On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
Post by Martin Langhoff
If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.
If we ban set{u,g}id binaries for dynamic uids, then we can just have
all files in /usr owned by root:root. Then there are two other
directories: /var and /etc. For /var, the model OSTree pushes towards
is one where /var should start completely empty. So dynamically
allocating uids works there.

However, /etc is still an issue; /etc/polkit-1/rules.d for example is
owned by polkitd:root. A quick run on my el7 workstation:

# find /etc '!' -uid 0 -o '!' -gid 0 | while read f; do rpm -qf $f;
done | sort -u
chrony-1.29.1-1.el7.x86_64
cups-1.6.3-14.el7.x86_64
mock-1.1.38-1.el7.noarch
ntp-4.2.6p5-18.el7.x86_64
paps-0.6.8-28.el7.x86_64
pesign-0.109-6.el7.x86_64
polkit-0.112-5.el7.x86_64
polkit-pkla-compat-0.1-4.el7.x86_64
wvdial-1.61-9.el7.x86_64
#

Why are the mock files in /etc owned by root:mock? It's not like
they're secret...I wonder if it's intentional.

Anyways yeah, a fair amount of stuff here. A possible model is to
patch the services to start as root, open up the config files they want
(readonly or writable as appropriate), then setuid. Would be fairly
invasive as far as code goes. Another is to just fall back to static
allocation for these. Another is to implement Lennart's suggestion of
dynamic population instead of having the files shipped as owned by the
uid/gid.
Miloslav Trmač
2014-04-11 17:05:14 UTC
Permalink
For the fedora-atomic work, the only not-in-Fedora package is shadow-utils
because it requires a patch, that still lives in my walters/rpm-ostree COPR.
http://lists.alioth.debian.org/pipermail/pkg-shadow-
devel/2014-March/010099.html
https://sourceware.org/bugzilla/show_bug.cgi?id=16142
What I'd like to open is a discussion about whether /usr/lib/passwd is the
right thing long term. I think it'd be very useful to support it short
term, but it's not perfect.
"Clearly not."

There is broad agreement that future access to the user database database
(both reading and writing) will be through sssd[1], and that the data model
of /etc/{passwd,shadow} is too restrictive--we already want/need to store
more data about users than those files allow us to. (E.g. language for
physical persons, better namespaces and more accurate password expiration
for all accounts.)

So, having /usr/lib/passwd storing the same limited set of data is not the
right long-term thing. Unfortunately, AFAIK the fuller interface isn't
ready yet.
The main case where it breaks is when you have a daemon that runs as
non-root and saves state, so you give it its own system user, but not a
reserved uid. Daemons in this class will have their uids effectively
ordered by package installation order =/
Other posts of the thread have brought up the issue of files owned by the
same account.[2]

In the really-long-term, really-hand-wavy, future, I think we need to move
away from the 32-bit UIDs[3], and instead use something much longer and
well-namespaced (REDHAT_EMPLOYEES/$name, REDHAT_SERVICE_ACCOUNTS/$name,
FEDORA_DAEMON_ACCOUNTS/$name, LOCAL_USER/$name, $windows_domain_name/$sid);
that would give us a much larger namespace, avoid SID->UID mapping
problems, and we could just do the allocation at packaging-time, using
FEDORA_DAAEMON_ACCOUNT/$name both in RPM metadata and a password database
snippet, without having to worry about overflowing the reserved 1000 UIDs.

AFAIK nobody is working on this, and it would be a huge change, so that's
not going to help in the medium term.
Mirek

[1] With really-early-boot-before-sssd processes using ~the existing glibc
interfaces and files to avoid a dependency loop.

[2] Overall I'm *strongly* convinced that the fully-stateless ==
fully-atomic-updates model is simply unworkable. We can have
stateless/atomic software installation, but we *absolutely do* need to
allow for arbitrary operations to be done on system's state between loading
the new version on disk and starting it. Fedora-atomic can have special
support for a few classes of state know in advance, but fully general
software needs fully general post-installation adjustments. (E.g., where
does ALTER TABLE ADD COLUMN on software upgrade fit in the Fedora-atomic
model?)

[3] This could work in the same way SELinux contexts now work in the
kernel, having a 32-bit UID as an internal identifier that changes between
reboots, and longer usernames as the long-term storage mechanism. New
syscalls would work directly with usernames; older applications would still
work with the UIDs and the APIs would work as long as they don't try to
store the UID values anywhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140411/dcb24e77/attachment.html>
Colin Walters
2014-04-11 17:08:49 UTC
Permalink
Post by Miloslav Trmač
So, having /usr/lib/passwd storing the same limited set of data is
not the right long-term thing. Unfortunately, AFAIK the fuller
interface isn't ready yet.
Yeah, it'd be nice to merge the accountsservice database in to the
system db. (And in general, have more consolidation among
shadow-utils/sssd/accountsservice)
Post by Miloslav Trmač
In the really-long-term, really-hand-wavy, future, I think we need to
move away from the 32-bit UIDs[3],
I agree:
http://www.redhat.com/archives/rhl-devel-list/2009-April/msg02456.html
Post by Miloslav Trmač
[2] Overall I'm strongly convinced that the fully-stateless ==
fully-atomic-updates model is simply unworkable. We can have
stateless/atomic software installation, but we absolutely do need to
allow for arbitrary operations to be done on system's state between
loading the new version on disk and starting it. Fedora-atomic can
have special support for a few classes of state know in advance, but
fully general software needs fully general post-installation
adjustments. (E.g., where does ALTER TABLE ADD COLUMN on software
upgrade fit in the Fedora-atomic model?)
An ExecStartPre= entry in the systemd unit.
Jan Zelený
2014-04-14 08:43:33 UTC
Permalink
Post by Colin Walters
Post by Miloslav Trmač
So, having /usr/lib/passwd storing the same limited set of data is
not the right long-term thing. Unfortunately, AFAIK the fuller
interface isn't ready yet.
Yeah, it'd be nice to merge the accountsservice database in to the
system db. (And in general, have more consolidation among
shadow-utils/sssd/accountsservice)
Post by Miloslav Trmač
In the really-long-term, really-hand-wavy, future, I think we need to
move away from the 32-bit UIDs[3],
http://www.redhat.com/archives/rhl-devel-list/2009-April/msg02456.html
Post by Miloslav Trmač
[2] Overall I'm strongly convinced that the fully-stateless ==
fully-atomic-updates model is simply unworkable. We can have
stateless/atomic software installation, but we absolutely do need to
allow for arbitrary operations to be done on system's state between
loading the new version on disk and starting it. Fedora-atomic can
have special support for a few classes of state know in advance, but
fully general software needs fully general post-installation
adjustments. (E.g., where does ALTER TABLE ADD COLUMN on software
upgrade fit in the Fedora-atomic model?)
An ExecStartPre= entry in the systemd unit.
I will play devil's advocate here:

1) What if I don't use systemd to start whatever program needs the updated
data? (might not be a daemon for example)

2) Wouldn't that start the migration script every time the daemon starts?
Doesn't sound like a pretty solution.


Thanks
Jan
Colin Walters
2014-04-14 14:29:59 UTC
Permalink
Post by Jan Zelený
1) What if I don't use systemd to start whatever program needs the updated
data? (might not be a daemon for example)
Right, for say Evolution which runs in a user session, it obviously has
to do any mail format migrations when it starts in the session.

One way to view this is we're making system software behave the same
way user session software always was forced to. And in a modern world
where we have systemd, everything is consistently tracked and logged.
Post by Jan Zelený
2) Wouldn't that start the migration script every time the daemon starts?
Doesn't sound like a pretty solution.
There are a few ways around this. The simplest is to keep around a
stamp file. It works a lot better of course if schema migrations are a
builtin function of the service.

Then again I'd say neither of these are good for services which are
actually important - if your servers are dedicated to running
Wordpress, you're probably going to want to manage it more directly and
not out of %post or ExecStartPre.
Lennart Poettering
2014-04-11 17:19:22 UTC
Permalink
Post by Miloslav Trmač
There is broad agreement that future access to the user database database
(both reading and writing) will be through sssd[1], and that the data model
of /etc/{passwd,shadow} is too restrictive--we already want/need to store
more data about users than those files allow us to. (E.g. language for
physical persons, better namespaces and more accurate password expiration
for all accounts.)
Uhmm, is there "broad agreement"? I beg to differ... I really don't see
sssd inside of OS containers. Sorry.

I also don't see sssd covering cases where /var is not around and where
we can "disconnected" updates, the way Colin suggests.

I also didn't see sssd in control of system users at all, but merely of
normal users.

Lennart
--
Lennart Poettering, Red Hat
Miloslav Trmač
2014-04-11 17:22:05 UTC
Permalink
Post by Lennart Poettering
Post by Miloslav Trmač
There is broad agreement that future access to the user database database
(both reading and writing) will be through sssd[1], and that the data
model
Post by Miloslav Trmač
of /etc/{passwd,shadow} is too restrictive--we already want/need to store
more data about users than those files allow us to. (E.g. language for
physical persons, better namespaces and more accurate password expiration
for all accounts.)
Uhmm, is there "broad agreement"?
Well, it covers sssd, realmd, accountsservice, shadow-utils, libuser;
that's most major projects actually managing the data.
Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140411/65d281aa/attachment.html>
&quot;Jóhann B. Guðmundsson&quot;
2014-04-13 21:41:13 UTC
Permalink
Post by Lennart Poettering
Post by Miloslav Trmač
There is broad agreement that future access to the user database database
(both reading and writing) will be through sssd[1], and that the data model
of /etc/{passwd,shadow} is too restrictive--we already want/need to store
more data about users than those files allow us to. (E.g. language for
physical persons, better namespaces and more accurate password expiration
for all accounts.)
Uhmm, is there "broad agreement"? I beg to differ... I really don't see
sssd inside of OS containers. Sorry.
I also don't see sssd covering cases where /var is not around and where
we can "disconnected" updates, the way Colin suggests.
I also didn't see sssd in control of system users at all, but merely of
normal users.
Right storing system users in ldap ( or in whatever centralized
authentication system ) is bad idea and should never be done.
( think mixed OS environments and SAN's lun etc. )

JBG
Colin Walters
2014-04-28 15:32:29 UTC
Permalink
On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters <walters at verbum.org>
Post by Colin Walters
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
I attempted to capture some of this discussion here:
https://bugzilla.gnome.org/show_bug.cgi?id=729118

If anyone has more thoughts/ideas please feel free to follow up here,
and I can update the bug, or comment on the bug directly.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140428/a8086e35/attachment.html>
Simo Sorce
2014-04-28 15:52:20 UTC
Permalink
Post by Colin Walters
On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters <walters at verbum.org>
Post by Colin Walters
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
https://bugzilla.gnome.org/show_bug.cgi?id=729118
If anyone has more thoughts/ideas please feel free to follow up here,
and I can update the bug, or comment on the bug directly.
I am still not convinced it is a good idea to split passwd in multiple
files, besides potentially affecting applications and backup tools and
custom scripts.
- How do you deal with conflicts ?
- What happen when an admin legitimately just use vipw and adds a system
user in /etc/passwd instead of one of the other 2 you mention ?
- How do you propose to resolve users from multiple files ?
- Are you going to introduce new nss modules ?
- Are you going to change pam_unix to lookup from all there files in
different ways ?

anything else ?

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Tomasz Torcz
2014-04-28 16:45:10 UTC
Permalink
Post by Simo Sorce
Post by Colin Walters
On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters <walters at verbum.org>
Post by Colin Walters
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
https://bugzilla.gnome.org/show_bug.cgi?id=729118
If anyone has more thoughts/ideas please feel free to follow up here,
and I can update the bug, or comment on the bug directly.
I am still not convinced it is a good idea to split passwd in multiple
files, besides potentially affecting applications and backup tools and
custom scripts.
- How do you deal with conflicts ?
- What happen when an admin legitimately just use vipw and adds a system
user in /etc/passwd instead of one of the other 2 you mention ?
- How do you propose to resolve users from multiple files ?
- Are you going to introduce new nss modules ?
- Are you going to change pam_unix to lookup from all there files in
different ways ?
Risking being totally offtopic, but would TCB solve all most of this issues?
www.openwall.com/tcb/ or http://www.openwall.com/presentations/Owl/mgp00020.html

It splits passwd into per-user files. It was discussed here few years ago:
https://lists.fedoraproject.org/pipermail/devel/2006-August/089224.html

Maybe it's time to revisit?
--
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzichubg at chrome.pl -- Baron Vladimir Harkonnen
Colin Walters
2014-04-28 17:15:59 UTC
Permalink
On Mon, Apr 28, 2014 at 12:45 PM, Tomasz Torcz <tomek at pipebreaker.pl>
Post by Tomasz Torcz
Risking being totally offtopic, but would TCB solve all most of this issues?
www.openwall.com/tcb/ or
http://www.openwall.com/presentations/Owl/mgp00020.html
It helps a little, but the problem here is not exactly about the
underlying data format, but more about the merge/upgrade logic, which
TCB by itself doesn't quite solve.

We would still need logic somewhere (likely ostree), like today how it
lives in RPM %post scripts to check whether users exist, and if not
create them. The binding between that logic and how the files get
created on disk is the hard problem.

Also I originally thought TCB was a good idea, but I got less excited
about it when I realized they'd just shifted setuid binaries to setgid.
To me it'd be far more valuable to go the whole way and have
authentication/passwd talk to a system service. Then you could even
implement stuff like rate limiting sanely.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140428/b8ea5ee5/attachment.html>
Simo Sorce
2014-04-28 17:39:39 UTC
Permalink
Post by Colin Walters
On Mon, Apr 28, 2014 at 12:45 PM, Tomasz Torcz <tomek at pipebreaker.pl>
Post by Tomasz Torcz
Risking being totally offtopic, but would TCB solve all most of this issues?
www.openwall.com/tcb/ or
http://www.openwall.com/presentations/Owl/mgp00020.html
It helps a little, but the problem here is not exactly about the
underlying data format, but more about the merge/upgrade logic, which
TCB by itself doesn't quite solve.
We would still need logic somewhere (likely ostree), like today how it
lives in RPM %post scripts to check whether users exist, and if not
create them. The binding between that logic and how the files get
created on disk is the hard problem.
Also I originally thought TCB was a good idea, but I got less excited
about it when I realized they'd just shifted setuid binaries to setgid.
To me it'd be far more valuable to go the whole way and have
authentication/passwd talk to a system service. Then you could even
implement stuff like rate limiting sanely.
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).

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Colin Walters
2014-04-28 18:50:57 UTC
Permalink
Post by Simo Sorce
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).

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140428/4af5a446/attachment.html>
Simo Sorce
2014-04-30 03:23:21 UTC
Permalink
Post by Colin Walters
Post by Simo Sorce
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 ?
Post by Colin Walters
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()
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.
--
Simo Sorce * Red Hat, Inc * New York
Colin Walters
2014-04-30 13:25:55 UTC
Permalink
Post by Simo Sorce
can you use an actual chroot ?
Calling chroot tends to imply running code from the target system. I'd
prefer to avoid that by default. In practice some things are going to
require it, but the more we can avoid it, the better.
Post by Simo Sorce
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 (?).
It's not about how heavy the use of fsync is - it's whether to do it at
all. There are two cases where we *don't* want to fsync - mock chroots
and initial installs in Anaconda. For the other cases, like upgrading
a running system, we do.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140430/9c4df9a5/attachment.html>
Simo Sorce
2014-04-30 14:30:44 UTC
Permalink
Post by Colin Walters
Post by Simo Sorce
can you use an actual chroot ?
Calling chroot tends to imply running code from the target system. I'd
prefer to avoid that by default. In practice some things are going to
require it, but the more we can avoid it, the better.
ok so the point you are making is that you'd want a way to just write
out a file on your own and have whatever mechanism provides users to the
system load it at the next startup and blow away the previous data ?
Post by Colin Walters
Post by Simo Sorce
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 (?).
It's not about how heavy the use of fsync is - it's whether to do it at
all. There are two cases where we *don't* want to fsync - mock chroots
and initial installs in Anaconda. For the other cases, like upgrading
a running system, we do.
Ok, understood, the above mechanism I described would be your favorite
way to avoid syncs ?

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Richard W.M. Jones
2014-05-05 13:27:39 UTC
Permalink
Post by Colin Walters
On Mon, Apr 28, 2014 at 12:45 PM, Tomasz Torcz
Post by Tomasz Torcz
Risking being totally offtopic, but would TCB solve all most of this issues?
www.openwall.com/tcb/ or
http://www.openwall.com/presentations/Owl/mgp00020.html
It helps a little, but the problem here is not exactly about the
underlying data format, but more about the merge/upgrade logic,
which TCB by itself doesn't quite solve.
We would still need logic somewhere (likely ostree), like today how
it lives in RPM %post scripts to check whether users exist, and if
not create them. The binding between that logic and how the files
get created on disk is the hard problem.
I think it would be better if we could declaratively say which user
accounts an RPM needs, and RPM can add or remove users from the system
based on this. eg. Apache httpd.spec would contain just:

%user apache
%group apache

(This applies to many other current uses of %post, such as enabling
services or running ldconfig.)

Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
Florian Weimer
2014-05-05 13:30:35 UTC
Permalink
Post by Richard W.M. Jones
I think it would be better if we could declaratively say which user
accounts an RPM needs, and RPM can add or remove users from the system
%user apache
%group apache
And if we had this, we could apply policy checks, such as ensuring that
the user does not already exist as a non-system account.
Post by Richard W.M. Jones
(This applies to many other current uses of %post, such as enabling
services or running ldconfig.)
Indeed.
--
Florian Weimer / Red Hat Product Security Team
Reindl Harald
2014-05-05 13:47:21 UTC
Permalink
Post by Richard W.M. Jones
I think it would be better if we could declaratively say which user
accounts an RPM needs, and RPM can add or remove users from the system
%user apache
%group apache
(This applies to many other current uses of %post, such as enabling
services or running ldconfig.)
that is missing the fixed userid 48 in case of httpd

this does matter if you have more than one machine
and need to rsync folders including their owners
and group permissions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140505/c9e5c2fb/attachment.sig>
Richard W.M. Jones
2014-05-05 17:02:06 UTC
Permalink
Post by Reindl Harald
Post by Richard W.M. Jones
I think it would be better if we could declaratively say which user
accounts an RPM needs, and RPM can add or remove users from the system
%user apache
%group apache
(This applies to many other current uses of %post, such as enabling
services or running ldconfig.)
that is missing the fixed userid 48 in case of httpd
It could be written:

%user --id=48 apache

or however.

dpkg triggers (discussed later on this list) are similar in intent,
but not quite declarative.

Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
Alexander Bokovoy
2014-04-28 16:51:10 UTC
Permalink
Post by Simo Sorce
Post by Colin Walters
On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters <walters at verbum.org>
Post by Colin Walters
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
https://bugzilla.gnome.org/show_bug.cgi?id=729118
If anyone has more thoughts/ideas please feel free to follow up here,
and I can update the bug, or comment on the bug directly.
I am still not convinced it is a good idea to split passwd in multiple
files, besides potentially affecting applications and backup tools and
custom scripts.
Just to make you aware, there are already schemes with shredded shadow
files, like TCB: http://www.openwall.com/tcb/

It stores a shadow file per each user and implements both NSS and PAM
modules to work with these files.

It is deployed for years in OpenWall, ALT Linux, and a number of other
distributions.
--
/ Alexander Bokovoy
Colin Walters
2014-04-28 16:48:22 UTC
Permalink
Post by Simo Sorce
- How do you deal with conflicts ?
- What happen when an admin legitimately just use vipw and adds a system
user in /etc/passwd instead of one of the other 2 you mention ?
- How do you propose to resolve users from multiple files ?
The answer to all 3 of these: /etc/passwd is writable by the admin, and
wins over anything else.
Post by Simo Sorce
- Are you going to introduce new nss modules ?
Yes, see nss-altfiles.
Post by Simo Sorce
- Are you going to change pam_unix to lookup from all there files in
different ways ?
Why would pam_unix need to be changed? It uses getpwnam() which will
be fine, AFAICS.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140428/bf411bb2/attachment.html>
Lennart Poettering
2014-04-28 16:00:18 UTC
Permalink
Post by Colin Walters
On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters <walters at verbum.org>
Post by Colin Walters
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
https://bugzilla.gnome.org/show_bug.cgi?id=729118
If anyone has more thoughts/ideas please feel free to follow up
here, and I can update the bug, or comment on the bug directly.
In the general case, system users cannot be defined in /var, since we
allow /var to be mounted late.

Defining essential users in /var also has the problem that they are lost
when the same /usr is used to boot a large number of instances with a
disjunct /var each time.

Lennart
--
Lennart Poettering, Red Hat
Continue reading on narkive:
Loading...