Bug 82041 - ignores wide links, serving files which shouldn't be served
ignores wide links, serving files which shouldn't be served
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: samba (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
David Lawrence
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-16 13:05 EST by Chris Ricker
Modified: 2014-08-31 19:24 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-08 03:00:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Ricker 2003-01-16 13:05:35 EST
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 17:52:43 EST
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 15:28:38 EST
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 14:42:20 EST
These were included in the current errata, right? Close this then?
Comment 4 Mark J. Cox (Product Security) 2003-04-08 03:00:50 EDT
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

Note You need to log in before you can comment on or make changes to this bug.