Bug#310982: plan to include in sarge 2.4 update
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
> the uid, gid, file_mode and dir_mode on the server will be used by the
> Did I understand correctly we would need to also patch samba ?
(Haroldo: complete history of this discussion is available at
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
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
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.