Bug 16931 - samba: proposed changes to smb.conf ([homes], map to guest)
Summary: samba: proposed changes to smb.conf ([homes], map to guest)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: samba (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2000-08-25 11:48 UTC by giulioo
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-23 19:16:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description giulioo 2000-08-25 11:48:30 UTC
I have rc1, don't know if maybe these changes are already in rc2.

Proposed changes to the smb.conf that get installed when you install samba.

1) Don't allow access to more things than expected:
Add to the [homes] section the following directive

valid users = %S

so that users won't be able to list homedirs other than their own and 
WRITE to public places the samba admin didn't think of...

A user, once logged into the linux server (telnet, ssh, ..), can certainly 
ls /
ls /var/spool/mail
touch /tmp/myfile

But there's no reason to allow a windows user do the same through network 

This is a known side effect of [homes]:

From windows try (without "valid users = %S"):
start, run, \\samba-server\nobody  \\samba-server\mail....
and you can traverse all the file system and write in places like /tmp.
Right now, if a samba admin sets up samba to only do [homes], a windows 
user that has access to his home share can even write to /tmp for 
instance, and this may be not evident to the admin.

2)  Just to get consistent behavior:
Add to the [homes] section the following directives

create mode = 0664
directory mode = 0775

so that files/dirs created through win get the same permissions of 
files/dirs created loggin into the linux server itself: 
664/775 instead of 744/755

3) Maybe to get less tech support questions:

Add the following directive, explains it and  _leave_ it commented

# map to guest = bad user

near the "security = user" line.

Say a samba admin sets up a share that is to be public, that is everyone 
should be able to access it, maybe just read-only. Right now if a windows 
users logins to MS Networks using an username that is not known to samba, 
he is denied access to that share even if the share is public.
The above directive allows the unknown username to be mapped to the guest 
user and allow the window user access to the public share.

This issue comes up frequently in newsgroups and lists "I've granted 
access to all and the user is denied access!". It's often linked to 
switching from "security = share" to "security = user" (samba 1.9.x -> 2.0 
Basically , for this specific case (access to public shares from unknown 
users) we can say that:
"security = share"  =  "security = user" + "map to guest = bad user".

You need to leave this commented, but well explained, since this may be 
considered less secure then the default "map to guest = never", and I 
don't know the NT behavior in such a case.

Comment 1 Trond Eivind Glomsrxd 2001-06-21 20:30:57 UTC
These changes will be part of 2.2.0-5

Comment 2 Trond Eivind Glomsrxd 2001-07-23 19:16:20 UTC
Which was put in rawhide a long time ago.. it's also present in the current,

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