Message-Id: <200810100036.m9A0aJc9004719@delorie.com>
To: cygwin AT cygwin DOT com
From: Herb Maeder <maeder-cygml AT maeder DOT org>
In-reply-to: Corinna Vinschen <corinna-cygwin@cygwin.com> 's message of                  Thu, 09 Oct 2008 13:05:36 +0200.
Subject: Re: invalid login gid in /etc/passwd does not show group name as 'mkgroup'
Date: Thu, 09 Oct 2008 17:35:23 -0700
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 09 Oct 2008 13:05:36 +0200, Corinna Vinschen wrote:
> On Oct  7 11:22, Herb Maeder wrote:
> > The "Special values of user and group ids" section of the Cygwin User's 
> > Guide (http://cygwin.com/1.7/cygwin-ug-net.html#ntsec-ids) states:
> > 
> >    Also, since Cygwin release 1.3.20, if the current user is present in 
> >    /etc/passwd, but that user's login group is not present in /etc/group,
> >    the group name will be shown as 'mkgroup', again indicating the 
> >    appropriate command.
> > 
> > I don't see that this holds true, at least for the case of a Domain User.
> > In fact, I see that an invalid login group id will be shown as a group
> > name of 'Domain Users' even though there is no such gid listed in
> > /etc/group. This can be confusing since things appear to work normally on
> > the surface, but some commands may fail in some not-so-obvious ways as a
> > result of the invalid login gid.
> > 
> > . . .
> > 
> > I'm not sure if this is specific to Domain Users or not.  Also I don't
> > know if there is some valid reason for this behavior.
> 
> It's not specific to "Domain Users" and there's no *valid* reason for
> this.  The whole idea (which is a couple of years old, from 2002
> actually) is that Cygwin tries to have valid passwd and group entries in
> memory for *at least* the current user.  So, the situation from Cygwin's
> point of view develops along these lines:
> 
>   First, Cygwin checks the user token and finds the user's primary
>   group SID.
> 
>   Next it checks /etc/passwd and finds that the pgid is 898.
> 
>   There's no /etc/group entry for the primary gid of the current user?
>   Ok, let's create one so that this gid makes sense.
> 
>   Grab the SID.  Check if there's a group entry corresponding to that
>   SID.  Gotcha.  It's the entry with gid 10513 (which is ignored) and
>   the name "Domain Users".
> 
>   Ok, so let's add a group entry in memory like this:
> 
>     Domain Users:S-1-5-21-1936786716-3317986166-2952453263-513:898:
> 
>   Bingo.  We now have two entries for Domain Users, one with gid 898
>   and one with 10513.

Thanks for the explanation.  The behavior makes sense to me now.  

But I think that means that some of the information in the "Special values
of user and group ids" section of the Cygwin User's Guide is out of date.

Would it be appropriate to include some of the information from your
description above in that section?

> It's well meant since you now see the real name of your primary group.
> And, in theory, nothing bad should happen since the underlying SID is
> correct.  But the outcome is somewhat puzzeling, whatever Cygwin does.
> For instance, the gid of a file depends on the numbers.  If the pgid is
> smaller than the real gid, files are owned by the faked pgid and vice
> versa.  Either way, id will show you two group entries which have the
> same meaning, even if the names would differ (Domain User/mkgroup).

Also, it should be noted that some applications may behave unexpectedly
because of the situation ("rsync --link-dest", for one).  But I think your
solution below will give the user fair warning that something may not be
quite right.

On 09 Oct 2008 14:14:54 +0200, Corinna Vinschen wrote:
> I changed the code to create a fake group name which should explain
> what's going on.  Or maybe confuse the crap out of you.  But at least
> it's something we can use here on the list:                          
>                                            
>   $ ls -l foobar
> -rw-r--r-- 1 herb passwd/group_GID_clash(898/10513) 0 Oct 7 10:27 foobar

Cool!  It ain't pretty, but it will certainly give the user a fighting
chance to detect the issue before it causes obscure problems later on.
Plus since it will show up in "cygcheck -s" output, it will be useful for
folks on this list, as you say.

Would it be possible to add a case for this group name in the /etc/profile
"id -ng" case statement so that the user will be notified and have some
idea of what it means and what to do about it?

The "passwd/group_GID_clash" group name probably also deserves a mention
in the Cygwin User's Guide.

Thank you for investigating this issue and implementing a reasonable 
solution.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/