More passwd/group patches

[Corinna Vinschen]

On Sun, Nov 24, 2002 at 09:21:20AM -0500, Pierre A. Humblet wrote:
> At 02:04 PM 11/24/2002 +0100, you wrote:
> 
> Hi Corinna,
> 
> First off I am going to look at the Win98 home directory problem 
> reported on the list, if you have not fixed it already.

I couldn't.  My VM struggled installing 98 the last few hours.
I really really hope this installation will not be that touchy.
Any success?  I assume it's the setting of myself->gid = DEFAULT_GID
at the beginning of internal_getlogin(), somehow.

> >I don't like the idea that these DENY bits are still set when the acl is
> >returned to the application.  The underlying Solaris acl implementation 
> >doesn't know about these bits.  They should be removed before returning
> >the acl to the application.  Otherwise you're using bits which are not
> >defined in acl.h.
> 
> That had crossed my mind. In fact acl.h does not declare any values for
> the a_perm field. Cygwin is simply reproducing the bits in the 
> user, group and other fields. I searched the web and saw that other
> versions of unix did not even agree on the type of the a_perm field (Cygwin
> makes it mode_t) and that the now-defunct standard proposal was silent on the 
> issue. So it seemed to me that all that mattered was consistency with
> the implementation of the routines getfacl, setfacl, etc... 
> I have no problem with masking them off. Defining specific bits in acl.h 
> would be nice in theory, but in absence of a standard perhaps not useful.

Note that acl.h is Solaris compatible.  It doesn't define anything
which isn't defined on Solaris.   The Solaris implementation is
NOT in any way compatible to the withdrawn POSIX proposal.  That
in turn means, Solaris is our role model when it comes to acl(2).

> >You're copying the group bits to the mask?  Didn't you suggest to set
> >it to rwx?  I think you're right.  It would be better to move this line
> >to the initialization of the first lacl members and change it to
> >
> Yes, but not knowing the reason for the current behavior I didn't want
> to change it. It doesn't hurt anything.
> >
> >Same here, shouldn't the DEF_CLASS_OBJ entry have rwx, too?
> >
> Same answer!

Actually, I've just checked on a Solaris box (SunOS 5.8) and except
for a definition problem related to the too releaxed usage of S_IREAD,
S_IWRITE and S_IEXEC, my getfacl utility runs on Solaris, too.  I
used gdb to look into the acl returned by acl(2) and found some
interesting facts:

- The permission bits used are only S_IROTH, S_IWOTH and S_IXOTH.
  No other bits are set...
- ...except for in the CLASS_OBJ entry.  The default setting on that
  machine for all my files is 0x1ff and, frankly, I have no idea
  how to explain that setting.  Interesting enough, the Solaris
  getfacl as well as my getfacl both return 'rwx' as permission bits
  for that entry.

- a_id = -1 in CLASS_OBJ and OTHER_OBJ entries.

I'm going to change getfacl(3) to use S_IROTH instead of S_IREAD etc. 

The appropriate changes to sec_acl.cc would collide with your patch
so I'd like to ask you if you want me to make the necessary changes
to comply with Solaris first and then to send a revised patch, or
if you want to incorporate these changes into your patch, too?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.