[PATCHES] Add vfs_admin vfs module

[Richard Sharpe]

On Sun, Oct 4, 2015 at 1:21 PM, Uri Simchoni <uri at samba.org> wrote:
>
>
> On 10/04/2015 10:11 PM, Richard Sharpe wrote:
>>
>> On Sun, Oct 4, 2015 at 11:22 AM, Uri Simchoni <uri at samba.org> wrote:
>>>
>>> Hi,
>>>
>>> This patch set adds vfs_admin, a simple vfs module that fixes file
>>> ownership
>>> for admin users.
>>> When a user is defined as an admin user, smbd runs as root, and files
>>> created by this user are
>>> owned by root. This patch fixes that by adding a vfs module to change the
>>> ownership of created objects.
>>>
>>> One thing worth noting is that for file creation I chose to override the
>>> NT-layer create_file function rather than the POSIX layer open, which
>>> would
>>> be more natural since this is a POSIX issue, created when running POSIX
>>> open() system call or something with similar semantics.
>>>
>>> The reason for that is that when open returns, the fsp is still not
>>> initialized with the just-created file descriptor, and so I cannot use
>>> SMB_VFS_FCHOWN from within the open handler, and have to resort to
>>> fchown()
>>
>> True. However, you do have access to the FD or pseudo FD so you could
>> update the FSP prior to calling the other VFS module.
>
> That's what I referred to as "hacking the fsp"... If I'm supposed to just
> return the FD, can I assume the FSP is "ready for use" except for the FD?
> Scanning the code it seems that vfs_fruit and vfs_streams_xattr take this
> approach though.
>>
>> Would it be better to require that the lowest module update the FSP
>> with the FD or pseudo FD as soon as it is available? Perhaps via an
>> accessor and a flag that tells us it has been updated?
>
> Seems like all the exiting VFS code (vfs_fruit and vfs_streams_xattr would
> prefer that SMB_VFS_OPEN update the FSP, and that code outside VFS wouldn't
> mind because the first thing it does is update the fsp.
>
> Update through accessors is also a good idea because that would let a VFS
> module swap FDs safely, in case there's more to it than calling
> SMB_VFS_CLOSE and assigning the new FD.
>
> That of course would break out-of-tree modules.

Those are on their own. In any case, we do not guarantee that we will
maintain the VFS across major version (4.3 to 4.4).

I want to try to get a major change in where all VFS functions return
NTSTATUS response.

We will see.

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