smbfs: bad interaction between uid= and CAP_UNIX, need advice for Debian sarge

Steve Langasek vorlon at
Wed Jun 1 12:14:29 GMT 2005

Hi folks,

Andrew Bartlett and I have been having a spirited discussion[1] about a
bug report from a Debian user(/developer) that the semantics of smbfs
silently change when upgrading to the latest Linux 2.4 kernels.  Because
smbfs now understands CAP_UNIX, the uid=, gid=, fmask=, dmask= mount options
are ignored when connecting to a Samba server in favor of passing through
the Unix permissions from the remote server.  This completely changes the
security model, and ties the security of the mount to the Unix uid layout of
the remote server, even when the user has explicitly requested otherwise at
mount time.

I think this is definitely a bug in the kernel smbfs implementation, but I'm
up against the wall for the sarge release on this one -- there's no way we'd
be able to get a kernel fix in before release, but we *could* conceivably
patch smbmount to strip CAP_UNIX from the capabilites before passing the
server info down to the kernel whenever the user specifies a uid= mount
option (or the like).

Andrew thinks this is a terrible idea :), I think it's perfectly reasonable
because people using such mount options are not likely to be concerned about
POSIX semantics on the mount point.  What do you all think?  Can I do this
without being lynched later, or should I punt this to be fixed as a kernel
security bug post-release?

Steve Langasek
postmodern programmer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :

More information about the samba-technical mailing list