> While there may be a patch for the specific issue, Jeremy made it pretty > clear that it's not suitable for setuid root status. This second bug > about the mtab corruption is another indicative. > > While it's a little more intrusive than other fixes, it appears to me > that the only correct fix for Lenny is also dropping the setuid root > bit while documenting the necessary dpkg-statoverride calls.
I went agin through upstream #6853 (https://bugzilla.samba.org/show_bug.cgi?id=6853) and I begin to be convinced that, yes, we should drop the setuid bit *even in Lenny*. It is very likely to break some existing setup but that really seems to be a trade-off with high security concerns. Steve, when discussing this, you were OK with dropping the setuid bit in squeeze (which we did...though I need now to upload) but at first glance, dropping it in lenny didn't have your favor. While I was originally having the same advice, I'm much more balanced right now, also because I looked at patches proposed in #6853 and I have doubts that my work on them to have them apply on Debian's 3.2.5 is correct. So, really now, I'm wondering whether dropping that setuid but wouldn't much safer. That's obviously breaking the principle of least surprise and need to document things in NEWS.Debian, including the use of dpkg-statoverride. Something like what we did put in NEWS.Debian for squeeze, but slightly more complete. * As of this version, the mount.cifs binary is no longer setuid. Upstream has always been increasingly unsupportive of this configuration over time. For instance, in bugs like https://bugzilla.samba.org/show_bug.cgi?id=6853, it is clearly mentioned that having it setuid root is discouraged. If you really rely on moiunt.cifs being setuid root, you need to use the following command: "dpkg-statoverride --add root root 4755 /sbin/mount.cifs" Be aware that this is highly discouraged by the Samba Team because mount.cifs code has not been deeply audited. > I also fail to see why mount.cifs/umount.cifs should be accessible > for a non-privileged user in the first place. Noone would even think > about doing that for NFS, so why should CIFS be any different? In #6853, there are mentions of KDE network browser relying on this.
signature.asc
Description: Digital signature
