|Summary:||ignores wide links, serving files which shouldn't be served|
|Product:||[Retired] Red Hat Linux||Reporter:||Chris Ricker <chris.ricker>|
|Component:||samba||Assignee:||Jay Fenlason <fenlason>|
|Status:||CLOSED ERRATA||QA Contact:||David Lawrence <dkl>|
|Version:||8.0||CC:||dkelson, jfeeney, kmaraas|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-04-08 07:00:50 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Chris Ricker 2003-01-16 18:05:35 UTC
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
Comment 1 Jay Fenlason 2003-01-31 22:52:43 UTC
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.
Comment 2 Jay Fenlason 2003-03-06 20:28:38 UTC
This is fixed in samba-2.2.8pre1 and later. I'll probably make errata after 2.2.8 is released.
Comment 3 Kjartan Maraas 2003-04-03 19:42:20 UTC
These were included in the current errata, right? Close this then?
Comment 4 Mark J. Cox 2003-04-08 07:00:50 UTC
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