Who should be the owner of newly created files when the creator is in the local Administrators group

[Andrew Bartlett]

On Sun, 2012-04-29 at 13:39 -0400, simo wrote:
> On Sat, 2012-04-28 at 21:52 -0700, Richard Sharpe wrote: 
> > Hi folks,
> > 
> > Here http://technet.microsoft.com/en-us/library/cc781716%28v=WS.10%29.aspx
> > it says:
> > 
> > "Note
> > 
> >     When users who are members of the local Administrators group
> > access objects on Windows Server 2003, the Default Owner field in the
> > user’s access token contains the SID for the Administrators group, not
> > the SID for the user. A similar rule applies to users who access
> > objects in Active Directory. If the user is a member of the Domain
> > Admins group, the Default Owner field in the user’s access token
> > contains the SID for the Domain Admins group. In both cases, objects
> > that the user creates or takes ownership of are owned by the group,
> > not by the individual user."
> > 
> > This suggests that we currently do the wrong thing, I think, when we
> > create a file and the creator is in the local Administrators group.
> 
> The problem is that in Posix, groups cannot own files.
> 
> Around the first time I put my hands in Idmap (2002/3 ?) I had a
> discussion with Tridge and Jeremy about changing samba to always
> allocate both a uid and a gid for any SID for 2 simple reasons:
> 1) It allows us to avoid resolving the SID at allocation time if we do
> not want to as we do not need anymore to check what it is.
> 2) It would allow groups to own files by using the "Group's UID".
> At that time it wasn't accepted as an idea, so samba 3.x never gained
> this ability.
> 
> Fast forward to samba 4 and now there is IDMAP_BOTH, which is
> essentially that proposal come true :-)
> 
> Unfortunately we still do not support IDMAP_BOTH in samba 3.
> Point is that it is an incompatible change, that you cannot turn on
> implicitly in existing installations.
> 
> That said I do support this method, so much so that in FreeIPA I also by
> default merged the id space, long ago, and effectively only have a
> unified ID space in the default install, as it makes it easier to handle
> personal user groups w/o polluting the tree with real fully featured
> groups.
> 
> So long story short, yes we should do what is suggested there, but
> before we can do it, we need to add the option to use IDMAP_BOTH in the
> File server, optionally. The ACL code needs to be changed to understand
> IDMAP_BOTH and Winbindd also need to be changed so that a direct lookup
> of a UID beloging to a Group returns an actual disabled user with the
> same name of the group, the same ID, but no password, no home, no shell,
> and an indicator in the Gecos that this is actually a group. We should
> never returns these entries in enumerations though. As they are not real
> users and you do not want to pollute user's lists in those installations
> that want to be able to list users and groups.

Given that this is on the critical path for Samba 4.0, expect to see
some movement on support in smbd for this in the near future.  The
patches to implement the smbd-side are under review with obnox at the
moment, and at some point the s3 winbindd will follow (required if we
want to switch winbindd implementations for the AD DC). 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org