This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Testers needed: New passwd/group handling in Cygwin

On Mar 11 15:07, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at>> writes:
> > You don't have to move them away.  Just set nsswitch.conf.
> Did that and using the snapshot DLL from 2014-03-05 on top of a full
> snapshot install from 2014-03-10.  The ACL is this:
> # file: x86
> # owner: gratz
> # group: Domain Users
> user::---
> group::---
> group:admin-cygwinupload:rwx
> group:user-cygwinupload:rwx
> mask:rwx
> other:---
> default:user::---
> default:group::---
> default:group:admin-cygwinupload:rwx
> default:group:user-cygwinupload:rwx
> default:mask:rwx
> default:other:---
> With the original passwd and group file in place and nsswitch.conf set to
> either "files" or "files db" the test fails.  With just "files" getfacl
> doesn't show the group ACL at all,

How does it look with any non-AD integrated Cygwin?

> while with "files db" I see the ACL for
> both the admin and the user group (both are not in the group file).  Setting
> to just "db" the ACL is shown as before and the test from Perl now succeeds!


>  In fact any combination that includes "files" fails.

Hmm.  So you're saying that the groups in question are not in
/etc/groups, but it works with the non-AD Cygwin but not with the
AD-Cygwin?  A group which is not in /etc/groups is, in theory, just not
in the ACL with the old Cygwin.  What's not in Cygwin anymore is the
mapping of a non-existing account to the uid/gid -1, what would have
been printed as "????????" in ls output.  This automatism would have
collided with the DB stuff, but maybe I have to re-introduce it if only
"files" is used.  This could explain what happens in the "files"-only

...but that doesn't explain what happens with "files db".  The uid/gid
values may differ from the DB values, but only if the account actually
exists in the file.  And then the values in the files would have
precedent over the db values.  I'm really wondering what perl is
checking there.

> So, after some head
> scratching I changed the uid and gid in the passwd and group files to match
> the new mapping scheme and lo and behold the test is now working.  The
> getfacl command starts to show the group ACL when I add them to the group
> file (with the correct gid mapping), but the test still fails with "files"
> only.  With the correct group entries and "files db", the test also works.


> So, Perl somehow uses the gid/uid mapping and relies on those to be working,

Whatever it's doing there.  That doesn't make sense, unless it calls
getgrent maybe?!?

> while bash uses a code path that doesn't and probably just uses the uid/gid
> directly.

Much easier.  bash just calls access(2).

> I guess I could make the "files" only case work by adding some
> more groups (no time for checking what that might be at the moment), again
> changing the mapping (will mkpasswd do this at some point?).  Do you still
> need traces or does get you a test case that works in your environment?

Yes, please.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpukoLm81KXb.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]