[Samba] Re: security=share, who needs it ?

[Tom Schaefer]

On Tue, 14 Mar 2006 23:05:48 +0100
Carsten Schaub <carsten-schaub at arcor.de> wrote:

> Hi list,
> 
> the security=share setting does not behave as many admins expect. Access

It behaves exactly as this admin expects and I would absolutely hate to see it to go.


> to all shares are mapped to the guest account and if the underlying unix
> permissions don't permit that access you get errors and the access
> doesn't work as expected.

Thats wrong.  You connect to a Samba server using security=share as the guest account or as any user you want.  The method used for determining whom you connect to a particular share as is spelled out in the section "NOTE ABOUT USERNAME/PASSWORD VALIDATION" of the smb.conf man page.

> 
> Also is security=share a global parameter. This given, there is no
> distinction between guest and authenticated access per share possible
> yet.
> 

No, no.  Here are a few shares from the smb.conf file of a single security=share server I have.  Homes only works for a given user if they give their correct password , the second share anyone who knows what the password is can access, and the guest share is a guest share so it works for everybody with no authentication. 

[Homes]
        comment = Home Directories
        username = %S
        valid users = %S
        writeable = Yes
        map archive = No
        browseable = No

[birdastudent]
        path = /accounts/faculty/birda
        follow symlinks = No
        username = birdastudent
        valid users = birdastudent
        writeable = No
        map archive = No
        browseable = No

[guest]
        path = /accounts/research/samba_guest
        guest only = Yes
        guest ok = Yes

> Further you can archieve the security=share setting behavior with
> setting 
> -----smb.conf--------
> [global]
> 	security = user     # thats the default of current releases
>         map to guest = bad user
>         username map = /etc/samba/smbusers
> 
> ----smbusers-----
> foo = *
> 
> What reasons prevent removing 'security=share' ?
> 
> 

One nice thing about security=share is that in an environment I'm in where there is little to no correlation between MS Windows usernames and UNIX account usernames I don't have to worry about trying to keep it all sorted out in some behometh username map file thanks to username = %S.  Another nice thing about it is I don't have to worry about the way MS Windows clients will only let you connect to a single server as a single user at a time.  With share level security I can have people authenticate to a single UNIX system as several different UNIX usernames from a single Windows box.