On Tue, Jun 07, 2005 at 07:44:25PM -0700, Steve Langasek wrote: > On Tue, Jun 07, 2005 at 06:42:33PM +0900, Horms wrote: > > On Mon, Jun 06, 2005 at 04:19:28AM -0700, Steve Langasek wrote: > > > reopen 310982 > > > tags 310982 security > > > thanks > > > > > > samba 3.0.14a-4 didn't make the cut for sarge, so this bug is still > > > present > > > in the release. That being the case, it would be far better to fix this > > > bug > > > in the kernel instead of in smbfs. > > > Hi Steve, > > > I'm kind of trying to read your mind here, but are you thinking > > of just making a kernel that doesn't do SMB_CAP_UNIX at all? > > I think the best answer is for the kernel to track whether > uid,gid,fmask,dmask options were specified, and if so, to ignore the > permission info sent by the CAP_UNIX-enabled server. > > That may require changes to the ioctl interface, though; I'd have to check > again whether there's any distinction between not setting the option, and > setting the option to 0.
Sorry for being slack about this. I scraped together a few moments to look into this. parse_options() in fs/smbfs/inode.c seems to handle the options parsed to a mount, and it does indeed seem to differentiate betwen an unset option and an option set to 0. I'll poke a bit futher to find where to put your suggested hack, but I have to run now. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]