[PATCH] s3: introduce new share parameter "open special files"

[Simo]

On 05/04/2013 04:12 AM, Volker Lendecke wrote:
> On Sat, May 04, 2013 at 08:11:59AM +1200, Andrew Bartlett wrote:
>> On Fri, 2013-05-03 at 13:31 +0200, Ralph Wuerthner wrote:
>>> On Fri, 3 May 2013 13:15:33 +0200
>>> Ralph Wuerthner <ralphw at de.ibm.com> wrote:
>>>
>>>> Hi list,
>>>>
>>>> attached patch introduces a new share parameter "open special files"
>>>> to control whether special files such as sockets, devices and fifo's
>>>> will be opened by the server or not. If set to "no" open requests to
>>>> special files will fail with "access denied". Default value for "open
>>>> special files" is "no".
>>>>
>>>> Access to special files impose a security risk because it may for
>>>> example allow remote clients raw access to local hard drives or
>>>> kernel memory.
>>>>
>>>> Regards
>>>>
>>>> 	Ralph
>>> I found a bug in above patch: the check for special files
>>> must be done after checking for directories. Otherwise opening a
>>> directory as a file will fail with "access denied" instead of "file is
>>> a directory".
>> So, does this pass a full 'make test' now?
>>
>> I'm quite sceptical about this patch - special files come in many types
>> - fifos that can and are used by folks for communication between clients
>> and server processes, and character devices that could plausibly be used
>> in the same way, and block devices/socket that are unlikely to make
>> sense remotely.
>>
>> Why set this to 'no' by default?  Remote access to kernel memory or
>> local hard drives would mean that either the remote user is root, or any
>> local user (or local process) on the system already has such access.
>>
>> Having Samba be the 'last line of defence' in this situation seems
>> wrong.  If these can somehow be created unsafely (backups of remote
>> sytstems for example), why not mount with 'nodev' and have the kernel
>> enforce this for everyone, and for all remote file servers, such as
>> http, afp and ftp?
> The use case is shared file systems between NFS / for
> diskless workstations and cifs. It's exactly the same
> argument we had with unix extensions and wide links. For
> NFS, device nodes are opened on the client side (symlinks
> are followed client-side), for Samba both are evaluated
> server-side. Those two concepts just don't match. In the
> discussion with wide links we opted to default on the safe
> side, disabling simultaneous unix extensions and wide links.
> I would argue that the same principle could be applied here.

This argument make sense, but if that's the case I would simply just 
extend the wide links option semantics and return the device node to a 
posix extensions enabled client so that it behaves like nfs and deny to 
non posix extensions enabled one.
I would see value in a patch that would do this, I see no value in the 
one that has been proposed.

Simo.