Samba has two options which control Samba's behavior when a Samba client requests a file which is a symbolic link. follow symlinks = yes instructs Samba to give the requesting client the target of the symlink If follow symlinks = yes, then a second option enters in: wide links = yes instructs Samba to serve the target of the symlink, even if the target is outside the directory space being shared wide links = no instructs Samba to serve the target of the symlink only when the target is within the directory space being shared This behavior is documented in the Samba documentation http://us2.samba.org/samba/docs/man/smb.conf.5.html#FOLLOWSYMLINKS http://us2.samba.org/samba/docs/man/smb.conf.5.html#WIDELINKS However, on Red Hat 8 (samba-2.2.5-10) this option does not work. Whether wide links = yes or wide links = no, targets of symlinks outside shared space are always served if follow symlinks = yes. This has the usual obvious security implications.... To reproduce this easily, on one machine use a trivial smb.conf file # cat /etc/samba/smb.conf [global] workgroup = EXAMPLE netbios name = station1 follow symlinks = yes [tmp] path = /tmp writeable = yes guest ok = yes wide links = no Then on that machine # cd /tmp # ln -s /etc/passwd . Connect from another machine (guest access is fine) and download passwd. Your download will succeed, even though it shouldn't
This only occurs on symlinks to files, rather than symlinks to directories. I get the same behavior with samba-2.2.7a on an OpenBSD-2.1 system, so this is either a generic Samba bug or an undocumented feature. I've opened a bug report upstream, so we'll see what they say. Note that this does not allow reading of files that the user cannot usually read: a symlink to /etc/shadow correctly returns "Access Denied" when a Windows client attempts to read it. Also note that any user that can create a symlink to /etc/passwd can also do "cp /etc/passwd resume.txt", so the actual security enhancement in blocking symlinks to files is minimal.
This is fixed in samba-2.2.8pre1 and later. I'll probably make errata after 2.2.8 is released.
These were included in the current errata, right? Close this then?
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2003-137.html