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

[Craig White]

On Fri, 2006-03-17 at 09:12 -0600, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Tom,
> 
> I've got to step up for Carsten here.
> 
> Tom Schaefer wrote:
> 
> > Carsten Schaub <carsten-schaub at arcor.de> wrote:
> >> the security=shre 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.
> 
> No.  it really doesn't.  For the record, Carsten brought
> this issue up on the samba-technical ml.  Every developer agrees
> that our security = share code is fundamentally broken because
> it tries to shoe horn a userless security model onto a user/password
> authentication system.
> 
> People try to do all sorts of silly things with security = share
> like using a 'write list' option.  What is that supposed to mean?
> You want a userless authentication but a user based authorization
> system?  That's just wrong.
> 
> If the only think people need is a guest server, we can do that
> very easily with 'security = user'.  We can even mix guest and
> non-guest servers using virtual servers.
> 
> >> 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.
> 
> Tom, I think it is a little more complicated that you realize.
> The problem is not getting 'security = share' to work with the
> current code base, but rather how easy it is to misconfigure
> the server.  And I'll add that if we implemented share mode
> security as it should be, your configuration would probably
> not work any more.
> 
> >> 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
> 
> See?  This this exactly what I'm talking about.  Why are you serving
> user home directories from a share mode based server?  The two model
> do not mix.  I will not support this type of configuration if
> something doesn't work as you expect because you are mixing userless
> authentication with user-based authorization.  And I go to a lot
> of lengths to support strange things.
> 
> > 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.
> 
> This is a buggy by product of the current code.  It make the
> code mind-numbingly hard to follow and really should work at all.
> In true share mode security you only have a readonly password
> and a write password.  Most like, we will either (a) implement
> a correct userless authentication/authorization model, or (b)
> mark 'security = share' as deprecated (along with 'security = server').
> 
> I'm still waiting for someone to give me a valid need to keep
> share security and I'm afraid this one doesn't qualify if only
> because it relies upon the obtuse behavior we want to get rid of.
> It does not really make user of share mode security at all.
> 
> No offense :-)
----
I can only think of one reason...I ran into that last night on
Fedora-list at redhat.com

User was connecting an old DOS client system to samba and had to use
'security = share'

of course, he was confused why the users homes directory didn't work ;-)

So I agree with you that the issue of 'security = share' isn't the
problem itself, it's the lack of understanding what the real nature of
the configuration represents and how it essentially obviates large
amounts of the other samba configuration details.

Craig