Bug 82041

Summary: ignores wide links, serving files which shouldn't be served
Product: [Retired] Red Hat Linux Reporter: Chris Ricker <chris.ricker>
Component: sambaAssignee: Jay Fenlason <fenlason>
Status: CLOSED ERRATA QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: dkelson, jfeeney, kmaraas
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-04-08 07:00:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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