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 13:18 -0700, Richard Sharpe wrote: 
> On 4/30/12, simo <idra at samba.org> wrote:
> > 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 :).
> 
> Oh my, so you mean that the system I work on works by magic? We have
> no posix ACLs and do not let any such thing get passed to the
> underlying file system (and it is accessed via user space.)

So you always do checks in samba and then change to root to open files ?
I did not recall this being allowed last time I wandered in this code,
but it was a while ago.

> >> 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.
> 
> I yield to your superior knowledge of the code I have been working on.

Obviously things have changed since last time I looked into this, no
need to be snarky.

Simo.

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