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

[Richard Sharpe]

On 4/30/12, Richard Sharpe <realrichardsharpe at gmail.com> 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.)

OK, so I have to apologize to Simo because there is some magic
happening here, that I forgot about.

In this case, like the Ceph VFS, our file system is kind of in
user-space. We have our own VFS that lives below acl_xattr, and even
though acl_xattr calls SMB_VFS_NEXT_SET_NT_ACL, we simply do nothing
but respond saying done.

So, there are no Posix acls involved, and thus, no need for any mapping.

There is, I believe, a use-case for this, because lots of NAS vendors
want only CIFS or only NFS behavior and do not want to get involved
with mixed CIFS and NFS support.

In that case a simple VFS could be written that does nothing with ACL
requests, and acl_xattr (or vfs_acl_common.c) could be given a
parameter to tell it what to do in the case I asked about above. If
the flag is set, it will convert the owner to BUILTIN\Administrators.
If not set, it will leave the owner as is.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)