Bug 17593 - Default für "wide links" ändern
Default für "wide links" ändern
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Samba
UCS 2.3
Other Linux
: P5 normal (vote)
: UCS 2.4
Assigned To: Stefan Gohmann
Arvid Requate
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-09 11:20 CET by Moritz Muehlenhoff
Modified: 2010-08-31 13:22 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Muehlenhoff univentionstaff 2010-02-09 11:20:58 CET
Von Jeremy Allison:

The problem comes from a combination of two features in
Samba, each of which on their own are useful to Administrators,
but in combination allow users to access any file on the system
that their logged in username has permissions to read (this is
not a privilege escalation problem).

By default Samba ships with the parameter "wide links = yes",
which allows Administrators to locally (on the server) add
a symbolic link inside an exported share which SMB/CIFS clients
will follow.

As an example, given a share definition:

[tmp]
        path = /tmp
        read only = no
        guest ok = yes

The administrator could add a symlink:

$ ln -s /etc/passwd /tmp/passwd

and SMB/CIFS clients would then see a file called "passwd"
within the [tmp] share that could be read and would allow
clients to read /etc/passwd.

If the "wide links" parameter is set to "no", any attempt
to read this file will fail with an "access denied" error.

The problem occurs as Samba allows clients using the UNIX
extensions (which are also turned on by default) to create
symlinks on remotely mounted shares on which they have write
access that point to any path on the file system.

This is by design, as applications running on UNIX clients
may have good reasons to create symlinks anywhere on the
filesystem they have write access that point to local files
(such as /etc/passwd).

UNIX clients will resolve these links locally, but Windows
clients will resolve them on the server. It is this combination
that causes the problem.

All future versions of Samba will have the parameter
"wide links" set to "no" by default, and the manual
pages will be updated to explain this issue.



Zur 2.4 sollten wir auch den Default ändern.
Comment 1 Stefan Gohmann univentionstaff 2010-05-26 21:27:31 CEST
Ist angepasst. Tests stehen noch aus.
Comment 2 Stefan Gohmann univentionstaff 2010-07-21 11:50:36 CEST
fixed

\item Der Default für die Samba"=Konfigurationsoption \ucsName{wide links}
wurde von \ucsName{yes} auf \ucsName{no} gesetzt. Die neue Standardeinstellung
kann über die \ucsUCRV{samba/wide\_links} überschrieben werden
(\ucsBug{17593}).
Comment 3 Arvid Requate univentionstaff 2010-08-11 15:56:26 CEST
Verified:
 * Default ist in smb.conf.d/61univention-samba_misc geändert.
 * Changelog ok
Comment 4 Arvid Requate univentionstaff 2010-08-25 14:59:53 CEST
Note: samba/wide_links=yes bringt alleine nichts, da der Samba default "unix extensions = yes" zur Zeit immer "wide links" deaktiviert (Logmeldung in log.smbd).
Comment 5 Stefan Gohmann univentionstaff 2010-08-31 13:22:49 CEST
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer
neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden:
"Clone This Bug".