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? Thanks, -- Steve Langasek postmodern programmer [1] http://bugs.debian.org/310982
signature.asc
Description: Digital signature
