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

[Jeremy Allison]

On Wed, Jun 01, 2005 at 05:14:29AM -0700, Steve Langasek wrote:
> 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?

Personally if you're worried about a security issue I'd say it's acceptable
to turn off CAP_UNIX until the kernel code gets fixed. Otherwise the user
gets suprised, and that's not good.

Jeremy.