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

[Volker Lendecke]

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.

With best regards,

Volker Lendecke

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de