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

[simo]

On Mon, 2012-04-30 at 07:26 -0700, Richard Sharpe wrote: 
> On Sun, Apr 29, 2012 at 10:39 AM, simo <idra at samba.org> 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.
> 
> Well, if acl_xattr (or even acl_tdb) is in use, we do not care at all
> about POSIX groups.

That's not true at all, even when using acl_xattr we still fill in posix
ACLs, as that's what's used by the system, and we still let the kernel
us posix acls to check access to the file (mostly :).

> So, from my perspective, modules/vfs_acl_common.c can get it right and
> things will be fine.

It's more complex that that, afaicr.

Jeremy,
care to comment ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>