ntsec patch 1: uid==gid, chmod, alloc_sd, is_grp_member

[Corinna Vinschen]

On Fri, Nov 15, 2002 at 09:31:24AM -0500, Pierre A. Humblet wrote:
> I am not familar with /var/empty. Is there a reason why 
> owner == group and the modes are not equal?

ssh-host-config calls

 chown system.system /var/empty
 chmod 755 /var/empty

sshd checks /var/empty for not having more than 755 permissions...

> This is an exceptional  case where a postinstall script might help.

Which only helps for new ssh versions.  It could change group like

  chgrp 544 or 513 /var/empty
  
but that only works for default /etc/group files.

> We discussed is_grp_member in get_nt_attribute and get_nt_object_attribute
> but this is VERY different. It's in alloc_sd.
> There is no good reason to call is_grp_member here. The old code was omitting
> the insertion of an owner_deny ace in that case. That's undesirable because
> it makes the acl ambiguous. Another bad side effect of omitting the deny ace
> is that if the groups of the owner of the file are changed, then the modes
> of the file might also change.

Uhm?  I don't understand.  The group_deny is only needed if the group
has more permissions than the user _and_ the user is a member of the
group.  What is ambiguous in that case?

> > >                      ace->Header.AceType == ACCESS_DENIED_ACE_TYPE ?
> > > -                    (owner_deny ? 1 : 0) : MAXDWORD,
> > > +                    ace->Mask & owner_allow ? owner_off + 1 : owner_off++
> > > +                    : MAXDWORD,
> > >                      (LPVOID) ace, ace->Header.AceSize))
> > 
> > After applying the patch to my local sandbox I found that I'm still
> > having problems here.  
> What problems?

These problems:

> > While I see the advantage for emulating POSIX
> > permissions closer, I also see that the probability is pretty high
> > that all unrelated deny ACEs will be placed after the owner_allow
> > (which probably has most bits set).  This doesn't really support the
> > wish to produce ACLs in canonical order.  So far, only the group_deny
> > could possibly but unlikely be placed after the owner_allow...
> > 
> This is really an issue I don't care about, there are very few unrelated
> deny ACEs out there. I thought that Cygwin approach was to try to conform 

I disagree.  I know how complex NT adminstration might become in a
complex environment (my friend is NT admin in a big government).

> to Posix, at the cost of possibly not respecting the canonical order.

Cygwin tries to be most POSIX compatible but we're also trying to stay
nice to the user.  The difference is, that so far a non-canonical order
is only created in the unlikely case of having the group more permissions
than the user and only if the user is a member of that group.  Your
solution is positioning nearly all deny ACEs after the user allow ACEs
since it's very likely that the unrelated ACE has some bit set which is
also set in the users ACE.

Corinna

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