On Tue, 14 Apr 2009 04:29:41 +1000, Cameron Simpson wrote: > On 13Apr2009 16:28, Carl D. Roth <roth@xxxxxxxxx> wrote: | Can some one > explain the following weird behavior with useradd? | # useradd -g mock > -r -m -d /var/lib/mockuser mockuser | --> create a new 'mockuser' user > that can be used to run /usr/bin/mock | # id mockuser > | uid=494(mockuser) gid=491(mock) groups=491(mock) | # grep mock > /etc/group > | mock:x:491:roth > | Hm, that's interesting, 'mockuser' is not in the 'mock' group. This > can | be verified using 'getgrent()'. > > If you look at /etc/passwd you will see the gid field there is "mock" > (494). Eg: > > $ grep cameron /etc/passwd > cameron:x:1000:1000::/home/cameron:/bin/zsh > > The -g option to useradd specifies the primary group, which is recorded > in the passwd file, not the group file. A UNIX user has a primary group > which comes from the passwd file and secondary groups which come from > the group file. Absent the setgid bit on a directory, new files and > directories a process makes get their group ownership from the primary > group. _Access_ (open, cd, etc) is governed by uid and all the groups. So from a UNIX programming perspective, then, a test for group membership is then: 1. is the user listed in the group membership list OR 2. is the user's primary group equal to the target gid That seems strange; it means that the group file is not canonical for establishing group permissions. C -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
