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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
