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

[Richard Sharpe]

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, 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.

> 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>
>
>


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