On Thu, Nov 16, 2006 at 10:51:24AM +0100, Bill Allombert wrote: > I am a bit concerned by the comment in the link you posted: > > To fully work, some modifications are needed to samba smbmount.c and > smbmnt.c files. Those patches are available at Samba and Kernel Bug > Tracker pages. > After those patches, if the user do not supply any of the parameters a > bove, > the uid, gid, file_mode and dir_mode on the server will be used by the > client. > > Did I understand correctly we would need to also patch samba ?
(Haroldo: complete history of this discussion is available at http://bugs.debian.org/310982) hey Bill - sorry for the delay, I put this on the back burner while I tried to get my etch packages into a releaseable state. I didn't notcie the note about the userspace patches initially, thanks for pointing it out. Here's what I can decipher about their purpose, based upon code reading (I've cc'd the author so he can correct me if I've misunderstood): The kernel patch has changed the behavior to honor mount options if specified instead of always relying on the remote server. The issue with that is that smbmount always passes these options to the kernel, even if not specified by the user. The smbmount patch changees that by only passing these options if the user included them. With this change, the user can omit these options if they want to fallback to the values provided by the remote server. If this reading is correct, I don't think its necessary for us to perform an security update of samba - in fact, it maybe risky to do so. Though less flexible, it seems safer to default to the locally formulated values than to use what the remote server provides. Also note that the userspace patches have not gone upstream (google returns no record of them being submitted), but the kernel one did. So, a kernel-only update would make sarge's behavior consistent with etch. The downside is that any sarge users who might be relying on the use-the-server-provided-value behavior will no longer have that option. I don't understand this case enough to know if it has any practical implications. I would guess it means something like if user dannf had mounted vorlon's share w/o any mount options, current sarge would make those files owned by vorlon locally - but with just this kernel patch they'd now be owned by dannf? Unless someone can explain this authoritatively, I guess we'll just need to test it. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
