Debian Bug report logs - #325558
login: newgrp quite broken?

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ian Zimmerman <itz@buug.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: login: newgrp quite broken?

Date: Mon, 29 Aug 2005 08:16:04 -0400

Package: login
Version: 1:4.0.3-31sarge5
Severity: normal

Thus "man newgrp":

The user will be prompted for a password if she do not have a password and  the
group does, or if the user is not listed as a member and the group has a password. The user will be denied
access if the group password is empty and the user is not listed as a member.

But:

itz@unicorn:~$ groups
itz cdrom floppy audio src games tex
itz@unicorn:~$ grep '^src:' /etc/group
src::40:itz
itz@unicorn:~$ sudo grep '^src:' /etc/gshadow
src:::
itz@unicorn:~$ newgrp src
Password: <I type my own here because I don't know what the h*l else I should do>
Sorry.

Moreover:

itz@unicorn:~$ sudo gpasswd src
Changing the password for group src
New Password: 
Re-enter new password: 
itz@unicorn:~$ newgrp src
Password: 

Also wrong, according to the manpage.


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-12custom3
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages login depends on:
ii  libc6                       2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libpam-modules              0.76-22      Pluggable Authentication Modules f
ii  libpam-runtime              0.76-22      Runtime support for the PAM librar
ii  libpam0g                    0.76-22      Pluggable Authentication Modules l

-- no debconf information

Message #10 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Nicolas François <nicolas.francois@centraliens.net>

To: Ian Zimmerman <itz@buug.org>, 325558@bugs.debian.org

Subject: Re: Bug#325558: login: newgrp quite broken?

Date: Mon, 29 Aug 2005 15:37:30 +0200

On Mon, Aug 29, 2005 at 08:16:04AM -0400, itz@buug.org wrote:
> Package: login
> Version: 1:4.0.3-31sarge5
> Severity: normal
> 
> Thus "man newgrp":
> 
> The user will be prompted for a password if she do not have a password and  the
> group does, or if the user is not listed as a member and the group has a password. The user will be denied
> access if the group password is empty and the user is not listed as a member.
> 
> But:
> 
> itz@unicorn:~$ groups
> itz cdrom floppy audio src games tex
> itz@unicorn:~$ grep '^src:' /etc/group
> src::40:itz
> itz@unicorn:~$ sudo grep '^src:' /etc/gshadow
> src:::

itz is not in the src group according to /etc/gshadow.
This line should have been src:::itz
This is probably because you edited /etc/group by hand instead of using
adduser, usermod or another tool aware of gshadow.

> itz@unicorn:~$ newgrp src
> Password: <I type my own here because I don't know what the h*l else I should do>
> Sorry.

With the modified /etc/gshadow, you should be able to have a your session
without being prompted a password.

> Moreover:
> 
> itz@unicorn:~$ sudo gpasswd src
> Changing the password for group src
> New Password: 
> Re-enter new password: 
> itz@unicorn:~$ newgrp src
> Password: 
> 
> Also wrong, according to the manpage.

Here, you were prompted for a password because you are not in the src
group (according to gshadow), but as you know the group password you are
anyway allowed to switch to this group.

The newgrp man page was modified in unstable. The paragraph you mentioned
is now:

   newgrp changes the current real group ID to the named group, or to  the
   default  group listed in /etc/passwd if no group name is given.  newgrp
   also tries to add the group to the user groupset. If not root, the user
   will  be  prompted for a password if she do not have a password and the
   group does, or if the user is not listed as a member and the group  has
   a  password.  The  user  will be denied access if the group password is
   empty and the user is not listed as a member.  If compiled with SHADOW-
   PWD (respectively SHADOWGRP) defined, the password of the user (respec-
   tively, the password and the members of the group) will be  overwritten
   by  the  value defined in /etc/shadow (respectively in /etc/gshadow) if
   an entry exists for this user (resp. group).

Do you think the end of the paragraph is clear enough?
(We are in the "compiled with SHADOWGRP" case, so "the password and the
members of the group" are "overwritten by  the  value defined in
/etc/gshadow" because "an entry exists for the src group".

Best Regards,
-- 
Nekral

Message #15 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Ian Zimmerman <itz@buug.org>

To: Nicolas François <nicolas.francois@centraliens.net>

Cc: 325558@bugs.debian.org

Subject: Re: Bug#325558: login: newgrp quite broken?

Date: 29 Aug 2005 20:21:10 -0400

Nicolas> The newgrp man page was modified in unstable. The paragraph you
Nicolas> mentioned is now:

Nicolas>    newgrp changes the current real group ID to the named group,
Nicolas> or to the default group listed in /etc/passwd if no group name
Nicolas> is given.  newgrp also tries to add the group to the user
Nicolas> groupset. If not root, the user will be prompted for a password
Nicolas> if she do not have a password and the group does, or if the
Nicolas> user is not listed as a member and the group has a password.
Nicolas> The user will be denied access if the group password is empty
Nicolas> and the user is not listed as a member.  If compiled with
Nicolas> SHADOW- PWD (respectively SHADOWGRP) defined, the password of
Nicolas> the user (respec- tively, the password and the members of the
Nicolas> group) will be overwritten by the value defined in /etc/shadow
Nicolas> (respectively in /etc/gshadow) if an entry exists for this user
Nicolas> (resp. group).

Nicolas> Do you think the end of the paragraph is clear enough?  (We are
Nicolas> in the "compiled with SHADOWGRP" case, so "the password and the
Nicolas> members of the group" are "overwritten by the value defined in
Nicolas> /etc/gshadow" because "an entry exists for the src group".

Thanks for your patient and clear explanation.

However:

- No, your man page patch is not enough.  The most important thing to
stress is that the group membership information must be duplicated in
gshadow. (or maybe that is the _only_ file that counts and group is
ignored?)  That's because this situation differs from the passwd/shadow
pair; I don't need to duplicate, e.g., users' shell, home directory or
even primary group in shadow.  So mine was a natural and easy mistake to
make.

- Even if documented, this situation still looks like a bug.  What is
the rationale for hiding the membership info in gshadow?  After all,
the primary group is plain for all to see in passwd.

- I wanted to complain that adding a supplementary group via the tools
was a pain, and it was with usermod (I had to find out the current
list of groups, then list them all again plus the new one on the
usermod command line).  But now I see "adduser <user> <group>" in
man adduser.  Well, good to know; I hope I can remember that, adduser
program name doesn't really help <frown>

Peace, Ian

-- 
Optimist: We're only two weeks behind schedule.
Pessimist: The schedule is a whole two weeks ahead of us.

Message #20 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@kheops.frmug.org>

To: Ian Zimmerman <itz@buug.org>

Cc: 325558@bugs.debian.org

Subject: (forw) Re: [Pkg-shadow-devel] Bug#325558: login: newgrp quite broken?

Date: Tue, 30 Aug 2005 08:55:24 +0200

I forgot sending to you and to the BTS..:-)

----- Forwarded message from Christian Perrier <bubulle@debian.org> -----

Date: Tue, 30 Aug 2005 08:50:22 +0200
From: Christian Perrier <bubulle@debian.org>
To: pkg-shadow-devel@lists.alioth.debian.org
Subject: Re: [Pkg-shadow-devel] Bug#325558: login: newgrp quite broken?


> - I wanted to complain that adding a supplementary group via the tools
> was a pain, and it was with usermod (I had to find out the current
> list of groups, then list them all again plus the new one on the
> usermod command line).  But now I see "adduser <user> <group>" in
> man adduser.  Well, good to know; I hope I can remember that, adduser
> program name doesn't really help <frown>

That's adduser package programs rationale: be high level tools, which
use is recommended in Debian

useradd and other user* and group* tools are part of the passwd
package and are intended to be lower level tools.

In short: if you want easy user management tools, use adduser.



_______________________________________________
Pkg-shadow-devel mailing list
Pkg-shadow-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-shadow-devel

----- End forwarded message -----

-- 

Message #25 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Nicolas François <nicolas.francois@centraliens.net>

To: Ian Zimmerman <itz@buug.org>, 325558@bugs.debian.org

Subject: Re: Bug#325558: login: newgrp quite broken?

Date: Tue, 30 Aug 2005 10:27:36 +0200

On Mon, Aug 29, 2005 at 08:21:10PM -0400, itz@buug.org wrote:
> 
> - No, your man page patch is not enough.  The most important thing to
> stress is that the group membership information must be duplicated in
> gshadow. (or maybe that is the _only_ file that counts and group is
> ignored?)  That's because this situation differs from the passwd/shadow
> pair; I don't need to duplicate, e.g., users' shell, home directory or
> even primary group in shadow.

See below.

> So mine was a natural and easy mistake to make.

I know, that's why the man page was already changed in unstable (and why I
would like to find the good explanation so that newgrp usage will be
clear).

> - Even if documented, this situation still looks like a bug.  What is
> the rationale for hiding the membership info in gshadow?  After all,
> the primary group is plain for all to see in passwd.

This situation does not looks like buggy per se to me. It is (just) a
documentation issue.
In fact, the information is not duplicated in /etc/group and /etc/gshadow.
The list of members in /etc/groups indicate the list of users who will
gain the permissions of this group.

The list of members in /etc/gshadow indicate the list of users who can
gain the permissions of this group by requesting them (with newgrp or sg,
without any password and this will be logged).

In passwd/shadow, if there is a password in both files, then the valid
password is the one from shadow (the password field is the only field that
is present in both files, no initial shell is specified in shadow)

Note:
The meaning of the fields in /etc/group are:
group_name:password:GID:user_list
The meaning of the fields in /etc/gshadow are:
group_name:password:administrator_list:user_list
So with group/gshadow, two fields may be confusing: password and user_list.
(A gshadow man page was added in the unstable package)


I propose to change the paragraph to:

   newgrp changes the current real group ID to the named group, or to  the
   default  group listed in /etc/passwd if no group name is given.  newgrp
   also tries to add the group to the user groupset. If not root, the user
   will  be  prompted for a password if she do not have a password
+  (in /etc/shadow if this has an entry in the shadowed password file, or
+  or in /etc/passwd otherwise)
                                                                   and the
   group does, or if the user is not listed as a member and the group  has
   a  password.  The  user  will be denied access if the group password is
   empty and the user is not listed as a member.
+  If there is an entry for this group in /etc/gshadow, then the list of
+  members and the password of this group will be taken from this file,
+  otherwise, the entry in /etc/group is considered.
-                                                 If compiled with SHADOW-
-  PWD (respectively SHADOWGRP) defined, the password of the user (respec-
-  tively, the password and the members of the group) will be  overwritten
-  by  the  value defined in /etc/shadow (respectively in /etc/gshadow) if
-  an entry exists for this user (resp. group).
   
Do you think this clearly explains the newgrp behavior?

Best Regards,
-- 
Nekral

Message #30 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Ian Zimmerman <itz@buug.org>

To: Nicolas François <nicolas.francois@centraliens.net>

Cc: 325558@bugs.debian.org

Subject: Re: Bug#325558: login: newgrp quite broken?

Date: 30 Aug 2005 18:54:06 -0400

Nicolas> This situation does not looks like buggy per se to me. It is
Nicolas> (just) a documentation issue.  In fact, the information is not
Nicolas> duplicated in /etc/group and /etc/gshadow.  The list of members
Nicolas> in /etc/groups indicate the list of users who will gain the
Nicolas> permissions of this group.

Nicolas> The list of members in /etc/gshadow indicate the list of users
Nicolas> who can gain the permissions of this group by requesting them
Nicolas> (with newgrp or sg, without any password and this will be
Nicolas> logged).

Let me read between your lines.

The membership list in /etc/group determines which users get the group
into their supplementary list during login (and, I guess, any other
program that calls initgroups (3)).

The membership list in /etc/gshadow determines which users can newgrp
or sg to the group.

Right?

Maybe the really counterintuitive thing here is that _either_ file
should be consulted for membership info when I am newgrping to a group
that is _already_ in my supplementary list.  I am not getting any new
privileges that way; all that changes is that new files will be created
owned by the other group, and I could do that already, with less
convenience, by using chgrp after the fact.

For my part I solved my "problem" by removing /etc/gshadow, as none of
my groups had passwords anyway.

-- 
Optimist: We're only two weeks behind schedule.
Pessimist: The schedule is a whole two weeks ahead of us.

Message #35 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Nicolas François <nicolas.francois@centraliens.net>

To: itz@buug.org, 325558@bugs.debian.org

Subject: Re: Bug#325558: login: newgrp quite broken?

Date: Wed, 31 Aug 2005 01:40:22 +0200

On Tue, Aug 30, 2005 at 06:54:06PM -0400, itz@buug.org wrote:
> 
> Nicolas> This situation does not looks like buggy per se to me. It is
> Nicolas> (just) a documentation issue.  In fact, the information is not
> Nicolas> duplicated in /etc/group and /etc/gshadow.  The list of members
> Nicolas> in /etc/groups indicate the list of users who will gain the
> Nicolas> permissions of this group.
> 
> Nicolas> The list of members in /etc/gshadow indicate the list of users
> Nicolas> who can gain the permissions of this group by requesting them
> Nicolas> (with newgrp or sg, without any password and this will be
> Nicolas> logged).
> 
> Let me read between your lines.
> 
> The membership list in /etc/group determines which users get the group
> into their supplementary list during login (and, I guess, any other
> program that calls initgroups (3)).

(Note that initgroups comes from the libc, which is not aware of the
gshadow file, so this is normal that this function does not use any
information from gshadow)

> The membership list in /etc/gshadow determines which users can newgrp
> or sg to the group.

With a fall back to /etc/group if there is no entry for the group in
gshadow (which is the case when you delete the gshadow file).

> Maybe the really counterintuitive thing here is that _either_ file
> should be consulted for membership info when I am newgrping to a group
> that is _already_ in my supplementary list.  I am not getting any new
> privileges that way; all that changes is that new files will be created
> owned by the other group, and I could do that already, with less
> convenience, by using chgrp after the fact.

Yes. unless in some rare cases, there is no need to change the primary
group.

However newgrp or sg can be used in another use cases: getting the
privileges of a group you are not in, by providing a password.
This can be used to setup boxes with a guest account and let some of the
guests gain more privileges. In those cases, guest is not a member of any
group (in /etc/group and /etc/gshadow), and the password of the privileged
group is distributed to some of the physical persons using the guest
account.

You can also imagine some configurations where somebody do not want to be
in a given group (to avoid mistake), but wants to be able to gain this
group privilege with newgrp (without password if this user is in the
member list in gshadow).

The gshadow file also permits to use group administrators (see
gpasswd(1)).

If you are not willing to do any of these, you can live without any notice
without the /etc/gshadow file.


I still have my question:
Do you think that the paragraph of my previous mail would have permitted
you to understand how newgrp works?

Regards,
-- 
Nekral

Message #40 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Ian Zimmerman <itz@buug.org>

To: Nicolas François <nicolas.francois@centraliens.net>

Cc: 325558@bugs.debian.org

Subject: Re: Bug#325558: login: newgrp quite broken?

Date: 30 Aug 2005 20:05:26 -0400

Nicolas> I still have my question: Do you think that the paragraph of my
Nicolas> previous mail would have permitted you to understand how newgrp
Nicolas> works?

You need to insert "user" after "this" in the first addition.

It's tough to give a yes/no answer.  Had the patch been applied, _and_
had I read it with a lawyer's eyes, then yes, I would have known how it
actually works.  But my presupposition that pre-existing supplementary
membership in the group would insulate me from being prompted would
still likely be so strong that my inner lawyer would take a coffee
break, and I would miss the literal meaning even as my eyes scanned over
it.

-- 
Optimist: We're only two weeks behind schedule.
Pessimist: The schedule is a whole two weeks ahead of us.

Message #45 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@debian.org>

To: Ian Zimmerman <itz@buug.org>, 325558@bugs.debian.org

Subject: Re: [Pkg-shadow-devel] Bug#325558: login: newgrp quite broken?

Date: Wed, 31 Aug 2005 06:46:36 +0200

Quoting Ian Zimmerman (itz@buug.org):
> 
> Nicolas> I still have my question: Do you think that the paragraph of my
> Nicolas> previous mail would have permitted you to understand how newgrp
> Nicolas> works?
> 
> You need to insert "user" after "this" in the first addition.
> 
> It's tough to give a yes/no answer.  Had the patch been applied, _and_


But, well, this is what we need...:-). Solving a bug requires an
action. Nicolas proposes one. The only thing we can decide is to
apply it or not....

From what you say, I'm more hearing a "yes" than a "no" and I'm
tempted to say Nicolas, go ahead and commit that fixes (also propose
it upstream) and close this bug.

We can nitpick wording for years and years, but frankly speaking I
need Nicolas competences for a lot of other stuff in shadow
maintenance..:-)

Message #54 received at 325558@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@debian.org>

To: 325558@bugs.debian.org, Tomasz Kłoczko <kloczek@zie.pg.gda.pl>

Subject: Patch for a more complete documentaiton of newgrp behaviour

Date: Sat, 8 Oct 2005 14:29:38 +0200

[Message part 1 (text/plain, inline)]

tags 325558 patch
thanks

Attached to this mail is Nicolas modifications to newgrp(1) so that it
better explains the issues experienced by the bug submitter in
http://bugs.debian.org/325558

Tomasz, can you mention us if you apply this to your CVS?


-- 

[newgrp.1.xml.diff (text/plain, attachment)]

Message #63 received at 325558-close@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@debian.org>

To: 325558-close@bugs.debian.org

Subject: Bug#325558: fixed in shadow 1:4.0.13-1

Date: Thu, 13 Oct 2005 11:32:08 -0700

Source: shadow
Source-Version: 1:4.0.13-1

We believe that the bug you reported is fixed in the latest version of
shadow, which is due to be installed in the Debian FTP archive:

login_4.0.13-1_i386.deb
  to pool/main/s/shadow/login_4.0.13-1_i386.deb
passwd_4.0.13-1_i386.deb
  to pool/main/s/shadow/passwd_4.0.13-1_i386.deb
shadow_4.0.13-1.diff.gz
  to pool/main/s/shadow/shadow_4.0.13-1.diff.gz
shadow_4.0.13-1.dsc
  to pool/main/s/shadow/shadow_4.0.13-1.dsc
shadow_4.0.13.orig.tar.gz
  to pool/main/s/shadow/shadow_4.0.13.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 325558@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Perrier <bubulle@debian.org> (supplier of updated shadow package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 10 Oct 2005 23:15:47 +0200
Source: shadow
Binary: login passwd
Architecture: source i386
Version: 1:4.0.13-1
Distribution: unstable
Urgency: low
Maintainer: Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>
Changed-By: Christian Perrier <bubulle@debian.org>
Description: 
 login      - system login tools
 passwd     - change and administer password and group data
Closes: 89902 115380 146779 208514 249372 265613 268656 269573 275343 282822 293171 300892 304343 304352 325558 325773 330630 330855 331487 331487 332711
Changes: 
 shadow (1:4.0.13-1) unstable; urgency=low
 .
   * The "Maroilles" release
   * New upstream version:
     Debian bugs fixed by the new upstream version:
     - faillog: Do not oversimplify the date of the last unsuccessful login
       Closes: #89902
     - login.1: also mention securetty(5). Closes: #325773
     - chfn.1, chsh.1, groupadd.8, newusers.8, pwconv.8
       useradd.8, userdel.8, usermod.8:
       Improved crossreferences with other manpages
       Closes: #300892
     - newgrp.1:
       Improved documentation of how group passwords work
       Closes: #325558
     - passwd.c:
       The usage line is no more too terse
       Closes: #146779
   * Patches to upstream man pages, not yet applied upstream:
     - debian/patches/452_doc_password_check_order:
       Document the order for checking the password strength
       Closes: #115380
   * Debian packaging fixes:
     - debian/login.su.pam:
       - pam_wheel example moved after pam_rootok in config.
         Also documents that with 'pam_wheel.so group=foo', root may need to
         be in the foo group. Closes: #330630, #330855
       - pam_env turned to be used as a session module which it is designed
         to be. Thanks to Steinar H. Gunderson who pointed this out and
         Steve Langasek and Andrew Suffield who suggested the right solution.
     - debian/control:
       - manpages-es-extra: versioned Replaces as the man pages have now been
                            removed
       - manpages-de:       versioned Replaces as the man pages have now been
                            removed
       - manpages-hu:       versioned Replaces as the man pages have now been
                            removed
     - debian/rules:
       - pack upstream's NEWS file into login and passwd. Closes: #331487
       - pack login.defs and its manpages into "passwd" instead of "login"
         package for the Hurd platform. Closes: #249372
       - copy upstream's changelog. Closes: #331487
     - debian/passwd.config, debian/passwd.templates:
       - allow preseeding the root (and user) password with a MD5 hash
         Closes: #275343, #304352
         Thanks to Colin Watson for the Ubuntu patch
       - the above also allows preseeding a disabled password for root
         Closes: #304343
       - add passwd/user-uid template, which can be preseeded to force the
         initial user to have a certain uid.
         Thanks to Colin Watson for the Ubuntu patch
       - allow hyphens in username
         Thanks to Colin Watson for the Ubuntu patch (Ubuntu #15721)
     - debian/login.defs:
       - document the obsoleted by PAM ENV_HZ variable. Closes: #265613
       - better document the real use of USERGROUPS_ENAB. Closes: #282822
     - debian/add-shell, debian/remove-shell, debian/add-shell.8,
       debian/remove-shell.8:
       - utilities moved to debianutils. Add a versioned "Depends" line on
         debianutils so that passwd cannot be upgraded when the new
         debianutils version including these utilities isn't available
         Closes: #208514, #268656, #269573, #293171
   * Debconf translation updates:
     - Swedish updated. Closes: #332711
Files: 
 261cbca719b22a396d2c38eab21e0f5b 867 admin required shadow_4.0.13-1.dsc
 034fab52e187e63cb52f153bb7f304c8 1622557 admin required shadow_4.0.13.orig.tar.gz
 3faf38ca58e4a594721f1068735ce920 181776 admin required shadow_4.0.13-1.diff.gz
 15e4ec0f57bdaf06bb3170d4de13867a 599276 admin required passwd_4.0.13-1_i386.deb
 087d22baecf6ef53ef8fb5e6d51564c1 560910 admin required login_4.0.13-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDTYDJ1OXtrMAUPS0RAvF5AJ49RdbhnKwV5mp6f+NY88B0/PzDyQCgpjoX
Jkjuz7tmFAhUmVxGJPtloRQ=
=9SLM
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.