Bug 82041

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>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0	CC:	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:
Embargoed:

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