group(5) Group Passwords do not work

Paul Schenkeveld freebsd at psconsult.nl
Fri Feb 8 10:10:13 UTC 2013


On Fri, Feb 08, 2013 at 09:21:42AM +0100, Dag-Erling Smørgrav wrote:
> Diane Bruce <db at db.net> writes:
> > It was also suggested on IRC that it is also possible that some pam
> > code does expect group passwords to work or at least passed through.
> 
> No, who gave you that idea?
> 
> The only places where gr_passwd is mentioned in head are:
> 
> contrib/mtree/getid.c
> include/grp.h
> lib/libc/gen/getgrent.3
> lib/libc/gen/getgrent.c
> lib/libutil/gr_util.c
> libexec/mknetid/parse_group.c
> share/man/man5/group.5
> tools/regression/lib/libc/nss/test-getgr.c
> tools/regression/lib/libutil/test-grp.c
> usr.bin/getent/getent.c
> usr.bin/logins/logins.c
> usr.bin/newgrp/newgrp.c

Newgrp still has the capability of letting non-root users change their
group to any group that the user can supply a correct group passord for.
To enable this capability do "chmod u+s /usr/bin/newgrp".  I suppose
this setuid bit was turned off by default long time ago as switching
groups became more or less redundant when supplementary group ID's were
introduced.  I've used newgrp quite a lot on old System V UNIX machines
back in the 1980's when supplementary group id's were not available.

So it's incorrect to sat that the password field in /etc/group does not
work and cannot work in FreeBSD.  After all /etc/group is just a database
containing group records and it's up to programs to decide what to do
with that data.  AFAIK this field is also part of the Posix standard so
it should stay there and the functionality in pw(8) and other programs
still matters if you happen to run software on your system that uses this
piece of data.

> usr.sbin/makefs/getid.c
> usr.sbin/nscd/agents/group.c
> usr.sbin/pw/pw_group.c

HTH,

Paul Schenkeveld


More information about the freebsd-arch mailing list