Possible UsersAndGroupsDraft

[Tom Callaway]

I'm not quite sure I'm ready to bring this to the FPC for a vote, but
I've been working on a modified version of Ville's draft:

http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft

While this is more complicated, I think it more adequately covers the
corner cases of adding users and groups. Thoughts?

~spot

[Axel Thimm]

On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote:
>  I'm not quite sure I'm ready to bring this to the FPC for a
> vote, but
>  I've been working on a modified version of Ville's draft:
>  
>  http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  
>  While this is more complicated, I think it more adequately covers the
>  corner cases of adding users and groups. Thoughts? 
It is far too complicated, Ville's version did the job already quite
well. You're also introducing non-standard tools again. :/
-- 
Axel.Thimm at ATrpms.net

[Tom Callaway]

On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote:
>  On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote:
>  > I'm not quite sure I'm ready to bring this to the FPC for a vote, but
>  > I've been working on a modified version of Ville's draft:
>  > 
>  > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  > 
>  > While this is more complicated, I think it more adequately covers the
>  > corner cases of adding users and groups. Thoughts?
>  
>  It is far too complicated, Ville's version did the job already quite
>  well. You're also introducing non-standard tools again. :/ 
Not really. The tools I introduced are helper scripts.

Ville's draft only created the user/group if it didn't exist, and if
not, didn't, but left the files owned as that user/group. That security
issue concerns me.

~spot

[Axel Thimm]

On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote:
>  On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote:
>  > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote:
>  > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but
>  > > I've been working on a modified version of Ville's draft:
>  > > 
>  > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  > > 
>  > > While this is more complicated, I think it more adequately covers the
>  > > corner cases of adding users and groups. Thoughts?
>  > 
>  > It is far too complicated, Ville's version did the job already quite
>  > well. You're also introducing non-standard tools again. :/
>  
>  Not really. The tools I introduced are helper scripts.
>  
>  Ville's draft only created the user/group if it didn't exist, and if
>  not, didn't, but left the files owned as that user/group. That security
>  issue concerns me. 
Yes, but the proposed complicated apparatus does not justify
this. Better to have %pre fail then and deal with the transaction
mess. After all how often will a sysadmin have created a non-system
user "amanda" (and accidentially install amanda w/o remembeing that he
had such a user)?

KISS.
-- 
Axel.Thimm at ATrpms.net

[Simo Sorce]

On Thu, 2007-06-14 at 17:25 +0200, Axel Thimm wrote:
>  On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote:
>  > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote:
>  > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote:
>  > > > I'm not quite sure I'm ready to bring this to the FPC for a vote,
> but
>  > > > I've been working on a modified version of Ville's draft:
>  > > > 
>  > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  > > > 
>  > > > While this is more complicated, I think it more adequately covers the
>  > > > corner cases of adding users and groups. Thoughts?
>  > > 
>  > > It is far too complicated, Ville's version did the job already quite
>  > > well. You're also introducing non-standard tools again. :/
>  > 
>  > Not really. The tools I introduced are helper scripts.
>  > 
>  > Ville's draft only created the user/group if it didn't exist, and if
>  > not, didn't, but left the files owned as that user/group. That security
>  > issue concerns me.
>  
>  Yes, but the proposed complicated apparatus does not justify
>  this. Better to have %pre fail then and deal with the transaction
>  mess. After all how often will a sysadmin have created a non-system
>  user "amanda" (and accidentially install amanda w/o remembeing that he
>  had such a user)? 
Axel, you couldn't choose a worst example :)

Amanda is also a real name (female in Italy), so it is plausible that
you have such user in your system.

It is also entirely possible that the admin does not know that such user
exists as users may come from ldap,nis,winbindd and not created by such
admin but by someone else.

I think at least a check to see if the "amanda" user is < 1000 would
make a lot of sense.

Simo.

[Axel Thimm]

On Thu, Jun 14, 2007 at 01:21:28PM -0400, Simo Sorce wrote:
>  On Thu, 2007-06-14 at 17:25 +0200, Axel Thimm wrote:
>  > On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote:
>  > > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote:
>  > > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote:
>  > > > > I'm not quite sure I'm ready to bring this to the FPC for a
> vote, but
>  > > > > I've been working on a modified version of Ville's draft:
>  > > > > 
>  > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  > > > > 
>  > > > > While this is more complicated, I think it more adequately covers
> the
>  > > > > corner cases of adding users and groups. Thoughts?
>  > > > 
>  > > > It is far too complicated, Ville's version did the job already quite
>  > > > well. You're also introducing non-standard tools again. :/
>  > > 
>  > > Not really. The tools I introduced are helper scripts.
>  > > 
>  > > Ville's draft only created the user/group if it didn't exist, and if
>  > > not, didn't, but left the files owned as that user/group. That security
>  > > issue concerns me.
>  > 
>  > Yes, but the proposed complicated apparatus does not justify
>  > this. Better to have %pre fail then and deal with the transaction
>  > mess. After all how often will a sysadmin have created a non-system
>  > user "amanda" (and accidentially install amanda w/o remembeing that he
>  > had such a user)?
>  
>  Axel, you couldn't choose a worst example :) 
I didn't choose it, it's in the proposal.

>  Amanda is also a real name (female in Italy), so it is plausible
> that
>  you have such user in your system. 
I know, it's very popular name especially in the US. I'm currently
reading baby name books ... ;)

>  It is also entirely possible that the admin does not know that such
> user
>  exists as users may come from ldap,nis,winbindd and not created by such
>  admin but by someone else. 
Well in that spirit it is also possible that the master admin manages
/usr/local and has put something else called amanda in there. The
point is we can't cater for all possible local configurations like
split adminstration, we need to make some assumptions to remain sane.

>  I think at least a check to see if the "amanda" user is
> < 1000 would
>  make a lot of sense. 
Then maybe it makes more sense to have "useradd -r" fail when the user
is > 500, e.g. outside the desired -r switch instead of obscuring the
specfiles with wrappers, scripts, registries and all that. :)
-- 
Axel.Thimm at ATrpms.net

[Simo Sorce]

On Thu, 2007-06-14 at 19:31 +0200, Axel Thimm wrote:
>  On Thu, Jun 14, 2007 at 01:21:28PM -0400, Simo Sorce wrote: 
>  > Axel, you couldn't choose a worst example :)
>  
>  I didn't choose it, it's in the proposal. 
I know :)

>  > Amanda is also a real name (female in Italy), so it is plausible
> that
>  > you have such user in your system.
>  
>  I know, it's very popular name especially in the US. I'm currently
>  reading baby name books ... ;) 
wow :)

>  > It is also entirely possible that the admin does not know that
> such user
>  > exists as users may come from ldap,nis,winbindd and not created by such
>  > admin but by someone else.
>  
>  Well in that spirit it is also possible that the master admin manages
>  /usr/local and has put something else called amanda in there. The
>  point is we can't cater for all possible local configurations like
>  split adminstration, we need to make some assumptions to remain sane. 
ok, I should have used the term plausible, and plausible is different
from possible.
So while I think it is possible but rare to find an admin to create a
directory that conflicts with a package it is instead plausible he find
a name in the user db that conflicts.

>  > I think at least a check to see if the "amanda" user
> is < 1000 would
>  > make a lot of sense.
>  
>  Then maybe it makes more sense to have "useradd -r" fail when the user
>  is > 500, e.g. outside the desired -r switch instead of obscuring the
>  specfiles with wrappers, scripts, registries and all that. :) 
dunno, maybe this is really better, but limiting system user to 500
could be a problem.

To be honest I think the username should always be configurable and
configuration be made by a config script run by the admin so that the
admin can take a conscious decision, but we are stuck with the fact that
rpm "owns" file (-V) and that it can't be interactive.

Simo.

[Axel Thimm]

On Thu, Jun 14, 2007 at 01:43:29PM -0400, Simo Sorce wrote:
>  So while I think it is possible but rare to find an admin to create
> a
>  directory that conflicts with a package it is instead plausible he find
>  a name in the user db that conflicts. 
Well, we were talking about split administration where one local admin
is not aware of the user the master admin manages.

And then the same master admin injects amada under
/usr/local/{bin,lib,...} and the local install (of a different
version) calls half under /usr and half under /usr/local (and remember
/usr/local takes precedence).

This scenario is just as plausible as the one with an amanda user (I'd
argue that a master admin centrally installing a backup solution is
far more common than having Amanda Lear with her first name in any
account), still we will not make loops and hardwire /usr everywhere,
the sources, specfiles etc.

>  > > I think at least a check to see if the "amanda"
> user is < 1000 would
>  > > make a lot of sense.
>  > 
>  > Then maybe it makes more sense to have "useradd -r" fail when the user
>  > is > 500, e.g. outside the desired -r switch instead of obscuring the
>  > specfiles with wrappers, scripts, registries and all that. :)
>  
>  dunno, maybe this is really better, but limiting system user to 500
>  could be a problem. 
That's a different story, we can't chose that number, that's given by
the FHS.

>  To be honest I think the username should always be configurable and
>  configuration be made by a config script run by the admin so that the
>  admin can take a conscious decision, but we are stuck with the fact that
>  rpm "owns" file (-V) and that it can't be interactive. 
You mean to choose at installtion time that httpd is not using the
user apache but say Donald? What about all the other packages that
make their bits owned by apache then? How would these packages know
what the base package is using for users and groups?
-- 
Axel.Thimm at ATrpms.net

[Simo Sorce]

On Thu, 2007-06-14 at 20:27 +0200, Axel Thimm wrote:

>  That's a different story, we can't chose that number,
> that's given by
>  the FHS. 
I know, it's a different (sad) story.

>  > To be honest I think the username should always be configurable
> and
>  > configuration be made by a config script run by the admin so that the
>  > admin can take a conscious decision, but we are stuck with the fact that
>  > rpm "owns" file (-V) and that it can't be interactive.
>  
>  You mean to choose at installtion time that httpd is not using the
>  user apache but say Donald? What about all the other packages that
>  make their bits owned by apache then? How would these packages know
>  what the base package is using for users and groups? 
The package need to provide this information, it's not difficult to do,
just put the user in a config file (you have to anyway) so that the
other packages can see it.

Simo.

[Stephen John Smoogen]

On 6/14/07, Simo Sorce <ssorce(a)redhat.com&gt; wrote:
>  On Thu, 2007-06-14 at 17:25 +0200, Axel Thimm wrote:
>  > On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote:
>  > > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote:
>  > > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: 
>  Axel, you couldn't choose a worst example :)
>  
Ok having had to tell people that they can't have the accounts root,
bin, sys or daemon just because thats their first or last name... if
there is an account name.. it will be used in the real world (god
knows how many people in boston or berkeley have changed their names
to Xyzzy.

There is no good solution for figuring out what a person's local
naming/UID scheme is. We can try and come up with lots of ways.. and
too many sites will have a name/number scheme that we will break
horribly.

We might as well prepopulate the /etc/passwd and /etc/group file with
100,200,500,etc  unused accounts with the names of "uid001/gid001" etc
And then either work out a cross distribution committee that works out
what future UID/GID should be for the billion odd packages are. Works
as well as any other scheme from what I can tell.


-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Ralf Corsepius]

On Thu, 2007-06-14 at 13:21 -0400, Simo Sorce wrote:
>  On Thu, 2007-06-14 at 17:25 +0200, Axel Thimm wrote:
>  > On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote:
>  > > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote:
>  > > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote:
>  > > > > I'm not quite sure I'm ready to bring this to the FPC for a
> vote, but
>  > > > > I've been working on a modified version of Ville's draft:
>  > > > > 
>  > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  > > > > 
>  > > > > While this is more complicated, I think it more adequately covers
> the
>  > > > > corner cases of adding users and groups. Thoughts?
>  > > > 
>  > > > It is far too complicated, Ville's version did the job already quite
>  > > > well. You're also introducing non-standard tools again. :/
>  > > 
>  > > Not really. The tools I introduced are helper scripts.
>  > > 
>  > > Ville's draft only created the user/group if it didn't exist, and if
>  > > not, didn't, but left the files owned as that user/group. That security
>  > > issue concerns me. 
Actually, I like Ville's proposal because of
it's simplicity and don't
see the potential security risk as critical, because user/group and
uid/gid handling always will require admin intervention.
 
>  > Yes, but the proposed complicated apparatus does not justify
>  > this. Better to have %pre fail then and deal with the transaction
>  > mess. After all how often will a sysadmin have created a non-system
>  > user "amanda" (and accidentially install amanda w/o remembeing that he
>  > had such a user)?
>  
>  Axel, you couldn't choose a worst example :) 
The worst case probably is using a "last name is username" convention
and your last name being "Root", "Mail" or "Windows" ;)

>  It is also entirely possible that the admin does not know that such
> user
>  exists as users may come from ldap,nis,winbindd and not created by such
>  admin but by someone else.
>  
>  I think at least a check to see if the "amanda" user is < 1000 would
>  make a lot of sense. 
I think restricting all rpm-created uids to < a limit (the value is
debatable) and presuming them to be local would be a reasonable
compromise

Ralf

[Axel Thimm]

On Fri, Jun 15, 2007 at 07:47:42AM +0200, Ralf Corsepius wrote:
>  Actually, I like Ville's proposal because of it's simplicity
> and don't
>  see the potential security risk as critical, because user/group and
>  uid/gid handling always will require admin intervention. 
+++++

>  The worst case probably is using a "last name is username"
> convention
>  and your last name being "Root", "Mail" or "Windows" ;)
"Hi, my name is Gopher, why does my sysadmin not give me an account?" ;)

>  > I think at least a check to see if the "amanda" user
> is < 1000 would
>  > make a lot of sense.
>  
>  I think restricting all rpm-created uids to < a limit (the value is
>  debatable) and presuming them to be local would be a reasonable
>  compromise 
Like Bill wrote, have useradd -r bail out if the uid is outside the
range.

But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones,
500-... for users. If you touch this (e.g. extend to 1000) you break a
lot of stuff like user homes.

We may need to do so some day, but this is so invasive that we
probably need to make a case before the LSB get some preapproval that
they recognise the need and will consider this topic for the next
draft and then start making lots of heads-up noise to have sysadmins
make space there in time (e.g. move their users to another id range).

Since this is a lot of effort required from various players we really
should very carefully consider when and what to ask for (e.g. ask for
1000 when two years later it will be considered that 2000 would had
been better and redo the whole dance?).

But the current discussion is orthogonal to this. It is very good that
this information is encapsulated in useradd, so the packages need not
know anything. So whenever these ranges (if ever change) all packages
will not even need a rebuild.

I vote for Ville's draft with a plea to the useradd maintainer to make
useradd -r fail if the result is that the uid/gid is not in the system
range. And also have the %pre script miseably fail to wake up the
sysadmin ("Hugh, we have a user called Gopher?").
-- 
Axel.Thimm at ATrpms.net

[Tom Callaway]

On Fri, 2007-06-15 at 09:38 +0200, Axel Thimm wrote:
>  Like Bill wrote, have useradd -r bail out if the uid is outside the
>  range.
>  
>  But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones,
>  500-... for users. If you touch this (e.g. extend to 1000) you break a
>  lot of stuff like user homes. 
I'm not opposed to this. Now, someone needs to figure out how.

>  I vote for Ville's draft with a plea to the useradd maintainer to
> make
>  useradd -r fail if the result is that the uid/gid is not in the system
>  range. And also have the %pre script miseably fail to wake up the
>  sysadmin ("Hugh, we have a user called Gopher?").  
The last part is not going to work. %pre can never fail, it will break a
transaction in unfortunate ways. Useradd can fail, but we need to
silently mask it. Output from %pre is not useful in a kickstart
transaction.

~spot

[Bill Nottingham]

Tom spot Callaway (tcallawa(a)redhat.com) said: 
>  > But the range is fixed, 0-99 for static ids, 100-499 for dynamic
> ones,
>  > 500-... for users. If you touch this (e.g. extend to 1000) you break a
>  > lot of stuff like user homes.
>  
>  I'm not opposed to this. Now, someone needs to figure out how. 
This *should* be a relatively simple patch to shadow-utils.

Bill

[Tom Callaway]

On Fri, 2007-06-15 at 09:53 -0400, Bill Nottingham wrote:
>  Tom spot Callaway (tcallawa(a)redhat.com) said: 
>  > > But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones,
>  > > 500-... for users. If you touch this (e.g. extend to 1000) you break a
>  > > lot of stuff like user homes.
>  > 
>  > I'm not opposed to this. Now, someone needs to figure out how.
>  
>  This *should* be a relatively simple patch to shadow-utils. 
*sniff, sniff*
I smell a volunteer!

~spot

[Axel Thimm]

On Fri, Jun 15, 2007 at 08:50:58AM -0500, Tom spot Callaway wrote:
>  On Fri, 2007-06-15 at 09:38 +0200, Axel Thimm wrote:
>  > Like Bill wrote, have useradd -r bail out if the uid is outside the
>  > range.
>  > 
>  > But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones,
>  > 500-... for users. If you touch this (e.g. extend to 1000) you break a
>  > lot of stuff like user homes.
>  
>  I'm not opposed to this. Now, someone needs to figure out how.
>  
>  > I vote for Ville's draft with a plea to the useradd maintainer to make
>  > useradd -r fail if the result is that the uid/gid is not in the system
>  > range. And also have the %pre script miseably fail to wake up the
>  > sysadmin ("Hugh, we have a user called Gopher?"). 
>  
>  The last part is not going to work. %pre can never fail, it will break a
>  transaction in unfortunate ways. Useradd can fail, but we need to
>  silently mask it. Output from %pre is not useful in a kickstart
>  transaction. 
Every silent recovery will bear security issues. Either the files get
owned by a user, or by root, both are not acceptable imo.

So we need to have this package installation fail. The issue with
depsolvers messing up a transaction needs to fixed irrespective of
this particular case.

And I think the fix is also rather simple (no, not volunteering!):
smart for example has a mode to install/remove package by package
instead of installing all packages and then uninstalling the old
ones. Whne something fails in this mode be it %pre or %post it only
messes up exactly zero to one packages (%pre zero, %post one).

An alternative route would be for yum to see that in a transaction
package $N failed and instead of bailing out directly after that to
run the clenup part for packages 1-($N-1). This also doesn't sound
like impossible to do (still not volunteering ;).

So it's a bug that looks fixable with sane effort and we should not
need to obfuscate specfiles or drop features like %pre exiting due to
that.
-- 
Axel.Thimm at ATrpms.net

[Jason L Tibbitts III]

> >>>> "RC" == Ralf Corsepius
> <rc040203(a)freenet.de&gt; writes: 
RC> The worst case probably is using a "last name is username"
RC> convention and your last name being "Root", "Mail" or
"Windows" ;)

If this really concerns us, then we could consider a naming policy for
system users.  Something like prefixing them with "sys-", maybe.
We've already broken the 8-character limit for system users
(haldaemon), so it's not as if this would be getting into new
territory.

 - J<

[Axel Thimm]

On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote:
>  On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote:
>  > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote:
>  > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but
>  > > I've been working on a modified version of Ville's draft:
>  > > 
>  > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  > > 
>  > > While this is more complicated, I think it more adequately covers the
>  > > corner cases of adding users and groups. Thoughts?
>  > 
>  > It is far too complicated, Ville's version did the job already quite
>  > well. You're also introducing non-standard tools again. :/
>  
>  Not really. The tools I introduced are helper scripts.
>  
>  Ville's draft only created the user/group if it didn't exist, and if
>  not, didn't, but left the files owned as that user/group. That security
>  issue concerns me. 
Looking at it again I think it doesn't improve if you elevate the
ownership to root. Imaging the package in question being ftp, http,
mldonkey or whatever daemon has been made non-root so a remote
attacker cannot elevate his priviledges. By making these root the
daemons have too much priviledges.

So please no silent failure and "recovery", if there is a broken
user/group better bail out of the transation. It really will be rare
corner case unless we get a daemon called Jacob or Emily (current top
baby names in the US ;=)
-- 
Axel.Thimm at ATrpms.net

[Ville Skyttä]

On Thursday 14 June 2007, Axel Thimm wrote:
>  On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote:
>  >
>  > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  >
>  > While this is more complicated, I think it more adequately covers the
>  > corner cases of adding users and groups. Thoughts?
>
>  It is far too complicated, 
Seconded.

By the way, chown/chgrp will fail eg. for files located in 
read-only %{_netsharedpath}s (typically /usr/share).

[Ralf Corsepius]

On Wed, 2007-06-13 at 23:45 -0500, Tom "spot" Callaway wrote:
>  I'm not quite sure I'm ready to bring this to the FPC for a
> vote, but
>  I've been working on a modified version of Ville's draft:
>  
>  http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  
>  While this is more complicated, I think it more adequately covers the
>  corner cases of adding users and groups. Thoughts? 
I am not convinced by your classification of cases:
<citation>
  * The user/group does not exist on the system 
      * The user/group exists from a previous package creating it 
      * The user/group is a normal user, overlapping the namespace (e.g.
        amanda) 
      * The user/group is pre-created by the administrator with a
        specific UID/GID 
<citation/>

IMO, this is only covers small subset of

 * user/group does/does not exist on the system
 * user/group has a privileged/non-privileged uid/gid
 * user/group needs a privileged uid/gid
 * user/group needs a fixed/doesn't need a fixed uid/gid
 * user/group is meant to be used locally/network-wide

Ralf

[Tom Callaway]

On Thu, 2007-06-14 at 10:41 +0200, Ralf Corsepius wrote:
>  On Wed, 2007-06-13 at 23:45 -0500, Tom "spot" Callaway
> wrote:
>  > I'm not quite sure I'm ready to bring this to the FPC for a vote, but
>  > I've been working on a modified version of Ville's draft:
>  > 
>  > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  > 
>  > While this is more complicated, I think it more adequately covers the
>  > corner cases of adding users and groups. Thoughts?
>  
>  I am not convinced by your classification of cases:
>  <citation>
>    * The user/group does not exist on the system 
>        * The user/group exists from a previous package creating it 
>        * The user/group is a normal user, overlapping the namespace (e.g.
>          amanda) 
>        * The user/group is pre-created by the administrator with a
>          specific UID/GID 
>  <citation/>
>  
>  IMO, this is only covers small subset of
>  
>   * user/group does/does not exist on the system
>   * user/group has a privileged/non-privileged uid/gid
>   * user/group needs a privileged uid/gid
>   * user/group needs a fixed/doesn't need a fixed uid/gid
>   * user/group is meant to be used locally/network-wide 
If the user exists, do we care (from a package perspective) what the
UID/GID is? I'd argue that we do not, as long as we can determine
whether we added it in a previous update or it came from some other
source. The user/group registries provide that functionality.

If the user/group needs a privileged UID/GID, the admin should add it in
advance. If the user/group needs a fixed UID/GID, the admin should add
it in advance. If the user/group is meant to be used network-wide, the
admin should add it in advance.

A possible improvement I could see would be to change the tool to ask
pam if the user exists, as opposed to simply looking
in /etc/passwd, /etc/group, as that would better cover network user
conflicts.

~spot

[Simo Sorce]

On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote:

>  A possible improvement I could see would be to change the tool to
> ask
>  pam if the user exists, as opposed to simply looking 
I guess you mean NSS

>  in /etc/passwd, /etc/group, as that would better cover network user
>  conflicts. 
If you don't already do it, you should _really_ do it and quickly.
Checking /etc/passwd directly today is not acceptable IMO, NSS has been
introduced exactly to decouple user querying from knowledge of the
underlying db and mechanisms used.

Simo.

[Tom Callaway]

On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote:
>  On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway
> wrote:
>  
>  > A possible improvement I could see would be to change the tool to ask
>  > pam if the user exists, as opposed to simply looking
>  
>  I guess you mean NSS
>  
>  > in /etc/passwd, /etc/group, as that would better cover network user
>  > conflicts.
>  
>  If you don't already do it, you should _really_ do it and quickly.
>  Checking /etc/passwd directly today is not acceptable IMO, NSS has been
>  introduced exactly to decouple user querying from knowledge of the
>  underlying db and mechanisms used. 
So... since I know pam but not NSS, is there a way to ask that question
(does a user/group exist) on the commandline with existing NSS tools?

~spot

[Jarod Wilson]

Tom "spot" Callaway wrote:
>  On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote:
> > On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote:
> >
> >> A possible improvement I could see would be to change the tool to ask
> >> pam if the user exists, as opposed to simply looking
> > I guess you mean NSS
> >
> >> in /etc/passwd, /etc/group, as that would better cover network user
> >> conflicts.
> > If you don't already do it, you should _really_ do it and quickly.
> > Checking /etc/passwd directly today is not acceptable IMO, NSS has been
> > introduced exactly to decouple user querying from knowledge of the
> > underlying db and mechanisms used.
>  
>  So... since I know pam but not NSS, is there a way to ask that question
>  (does a user/group exist) on the commandline with existing NSS tools? 
Do these achieve the desired results?

# getent passwd | cut -d: -f1 | grep -c <user>

# getent group | cut -d: -f1 | grep -c <group>

Fully nss-aware, pulls user and group stuff from nis, ldap, etc., as
well as local files.


-- 
Jarod Wilson
jwilson(a)redhat.com

[Tom Callaway]

On Thu, 2007-06-14 at 10:44 -0400, Jarod Wilson wrote:
>  Tom "spot" Callaway wrote:
>  > On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote:
>  >> On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote:
>  >>
>  >>> A possible improvement I could see would be to change the tool to ask
>  >>> pam if the user exists, as opposed to simply looking
>  >> I guess you mean NSS
>  >>
>  >>> in /etc/passwd, /etc/group, as that would better cover network user
>  >>> conflicts.
>  >> If you don't already do it, you should _really_ do it and quickly.
>  >> Checking /etc/passwd directly today is not acceptable IMO, NSS has been
>  >> introduced exactly to decouple user querying from knowledge of the
>  >> underlying db and mechanisms used.
>  > 
>  > So... since I know pam but not NSS, is there a way to ask that question
>  > (does a user/group exist) on the commandline with existing NSS tools?
>  
>  Do these achieve the desired results?
>  
>  # getent passwd | cut -d: -f1 | grep -c <user>
>  
>  # getent group | cut -d: -f1 | grep -c <group>
>  
>  Fully nss-aware, pulls user and group stuff from nis, ldap, etc., as
>  well as local files. 
Awesome. fedora-uidgid-tools 0.2 uses getent now, so that issue is
covered.

Thanks,

~spot

[Simo Sorce]

On Thu, 2007-06-14 at 10:44 -0400, Jarod Wilson wrote:
>  Tom "spot" Callaway wrote:
>  > On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote:
>  >> On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote:
>  >>
>  >>> A possible improvement I could see would be to change the tool to ask
>  >>> pam if the user exists, as opposed to simply looking
>  >> I guess you mean NSS
>  >>
>  >>> in /etc/passwd, /etc/group, as that would better cover network user
>  >>> conflicts.
>  >> If you don't already do it, you should _really_ do it and quickly.
>  >> Checking /etc/passwd directly today is not acceptable IMO, NSS has been
>  >> introduced exactly to decouple user querying from knowledge of the
>  >> underlying db and mechanisms used.
>  > 
>  > So... since I know pam but not NSS, is there a way to ask that question
>  > (does a user/group exist) on the commandline with existing NSS tools?
>  
>  Do these achieve the desired results? 
No.

>  # getent passwd | cut -d: -f1 | grep -c <user>
>  
>  # getent group | cut -d: -f1 | grep -c <group> 
It is advised to query the specific name required, the posix
specification allow for backends not to reply all or any of the accounts
in the db. But you have to replay if a specific user/group is requested.

On very large environments (nis, ldap, winbindd) listing all the
accounts and then grepping out the one you need is a complete waste of
resources anyway and also a possibly very, very long operation.

so the right method might be:

getent passwd <user> >/dev/null
getent group <group> >/dev/null

if the user/group exist then 0 is returned if not then non zero (2 iirc)
is returned

Simo.

[Simo Sorce]

On Thu, 2007-06-14 at 13:17 -0400, Simo Sorce wrote:

>  It is advised to query the specific name required, the posix
>  specification allow for backends not to reply all or any of the accounts 
I meant "enumerate" not "reply" here ----^^^^^^^

[Axel Thimm]

On Thu, Jun 14, 2007 at 01:17:21PM -0400, Simo Sorce wrote:
>  On Thu, 2007-06-14 at 10:44 -0400, Jarod Wilson wrote:
>  > Tom "spot" Callaway wrote:
>  > > On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote:
>  > >> On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote:
>  > >>> A possible improvement I could see would be to change the tool to ask
>  > >>> pam if the user exists, as opposed to simply looking
>  > >> I guess you mean NSS
>  > > So... since I know pam but not NSS, is there a way to ask that question
>  > > (does a user/group exist) on the commandline with existing NSS tools?
>  > # getent passwd | cut -d: -f1 | grep -c <user>
>  > # getent group | cut -d: -f1 | grep -c <group>
>  getent passwd <user> >/dev/null
>  getent group <group> >/dev/null 
`id' feeds of nss just like getent. Ville's draft already was nss
safe. ...
-- 
Axel.Thimm at ATrpms.net

[Jarod Wilson]

Simo Sorce wrote:
>  On Thu, 2007-06-14 at 10:44 -0400, Jarod Wilson wrote:
> > # getent passwd | cut -d: -f1 | grep -c <user>
> >
> > # getent group | cut -d: -f1 | grep -c <group>
>  
>  It is advised to query the specific name required, the posix
>  specification allow for backends not to reply all or any of the accounts
>  in the db. But you have to replay if a specific user/group is requested.
>  
>  On very large environments (nis, ldap, winbindd) listing all the
>  accounts and then grepping out the one you need is a complete waste of
>  resources anyway and also a possibly very, very long operation.
>  
>  so the right method might be:
>  
>  getent passwd <user> >/dev/null
>  getent group <group> >/dev/null
>  
>  if the user/group exist then 0 is returned if not then non zero (2 iirc)
>  is returned 
That is indeed a superior way to go, and you're correct on the exit
values. And 'getent' seems slightly more flexible than 'id' when it
comes to finding out about groups, at least at a glance.

-- 
Jarod Wilson
jwilson(a)redhat.com

[Simo Sorce]

On Thu, 2007-06-14 at 09:20 -0500, Tom "spot" Callaway wrote:
>  On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote:
>  > On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote:
>  > 
>  > > A possible improvement I could see would be to change the tool to ask
>  > > pam if the user exists, as opposed to simply looking
>  > 
>  > I guess you mean NSS
>  > 
>  > > in /etc/passwd, /etc/group, as that would better cover network user
>  > > conflicts.
>  > 
>  > If you don't already do it, you should _really_ do it and quickly.
>  > Checking /etc/passwd directly today is not acceptable IMO, NSS has been
>  > introduced exactly to decouple user querying from knowledge of the
>  > underlying db and mechanisms used.
>  
>  So... since I know pam but not NSS, is there a way to ask that question
>  (does a user/group exist) on the commandline with existing NSS tools? 
$ getent passwd spot
spot:*:1234:4567:Tom (spot) Callaway:/home/spot:/bin/bash


Simo.

[Simo Sorce]

On Wed, 2007-06-13 at 23:45 -0500, Tom "spot" Callaway wrote:
>  I'm not quite sure I'm ready to bring this to the FPC for a
> vote, but
>  I've been working on a modified version of Ville's draft:
>  
>  http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  
>  While this is more complicated, I think it more adequately covers the
>  corner cases of adding users and groups. Thoughts? 
+1

BUT, you need to find a way to cover cases where the user db is shared
between multiple systems.
Requiring the manifest to be equally shared could be one solution, but
cumbersome.
Another simpler and more effective way is to use the Gecos field (for
users, for groups I have no idea yet) to mark the account as a system
account as opposed to a normal user account. Can be done by adding a ",
SYSTEM" keyword at the end of the Gecos field.

Simo.

[Bill Nottingham]

Tom spot Callaway (tcallawa(a)redhat.com) said: 
>  I'm not quite sure I'm ready to bring this to the FPC for a
> vote, but
>  I've been working on a modified version of Ville's draft:
>  
>  http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  
>  While this is more complicated, I think it more adequately covers the
>  corner cases of adding users and groups. Thoughts? 
Seems overly complicated. I would rather just have useradd fail
for system users if the user/group exists outside of the predetermined
range. (And, yes, use static ids less than 500 for everything.)

Bill

[Axel Thimm]

On Fri, Jun 15, 2007 at 12:41:43AM -0400, Bill Nottingham wrote:
>  Tom spot Callaway (tcallawa(a)redhat.com) said: 
>  > I'm not quite sure I'm ready to bring this to the FPC for a vote, but
>  > I've been working on a modified version of Ville's draft:
>  > 
>  > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft
>  > 
>  > While this is more complicated, I think it more adequately covers the
>  > corner cases of adding users and groups. Thoughts?
>  
>  Seems overly complicated. I would rather just have useradd fail
>  for system users if the user/group exists outside of the predetermined
>  range. 
+1

>  (And, yes, use static ids less than 500 for everything.) 
No, please. Let's not violate the LSB for no good reason, and break
backwards compatibility to Fedora <= 7 in passing.

The only valid reason for static ids was to keep them the same across
a site network and we decided to allow the sysadmin to preoccupy the
uid/gid space with his local favourite mapping. See Ville's draft and
notes to it.
-- 
Axel.Thimm at ATrpms.net