Dear sirs, It's been a long time since I've made those patches but I have never known why the user level patches were not applied. I still think they are necessary.
Haroldo On Mon, 2006-11-27 at 19:27 -0700, dann frazier wrote: > 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. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
