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

[Tom Schaefer]

On Fri, 17 Mar 2006 09:12:52 -0600
"Gerald \(Jerry\) Carter" <jerry at samba.org> 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.
> 

I don't know if it behaves as other admins expect but it is does behave as I expect.  I've tinkered with it, read the man pages, and learned how it behaves.  I know Carsten brought the issue up on samba-technical because as soon as I saw his post here I kind of phreaked out fearing the conversation might be occurring elsewhere as well.  Its a conversation I don't want to see anywhere, so I Googled it and to my dismay I found the big discussion you all are having over on Samba technical.  I've read pretty much all of it.  

> 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.
> 

Well I've never attempted to do that and a quick review of the man page tells me I can't do it under Samba 3 even if I want to.  So, I'm not going to address it other than to say what you trying to bang over my head as well - share level security is not a "userless authentication" in Samba and its presumptuous to assume thats what the admin wants.  Perhaps the admin understands that even under share level security Samba always makes the connection as somebody, understands whom that somebody is can easily be controlled, and finds it advantageous to do so.

> 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.
>

With security=user you've still got to successfully connect as some user in the first place before you can even request a guest share.  This leads to all sorts of fun.  You'll still have situations where Joe User is going to find it difficult at best to actually connect to a guest share because he doesn't know his password, why should he need to know his password to access the guest share?  (Its a rhetorical question I understand the technical reason why)  Enter "map to guest", more fun, he'll make a typo on his username or password and get connected to the guest share as the guest account and subsequently not be able to connect to his non guest shares.

With security=share a guest share is always a guest share is always a guest share, no issues, no hassles, no muss, no fuss, it just works, always.

As far as virtual servers, they confuse people.  Also, they don't work unless you disable port 445..

     %L   the NetBIOS name of the  server.  This  allows  you  to
          change  your config based on what the client calls you.
          Your server can have a ``dual personality''.

          This parameter is not available when Samba  listens  on
          port 445, as clients no longer send this information.

I can go on about virtual servers Jerry, just ask me.
 
> >> 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.
> 

So, you're going to yank it out to protect me from myself.  It wasn't THAT long ago it was the DEFAULT.  I think making security=user the default as you've already done is sufficient to protect admins from themselves.  Might I remind you Samba runs on UNIX and UNIX like OSes where as root I can type type rm -rf / or a jillion other as disruptive commands with nary a single word of warning put before my eyes.

> >> 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

Some clients can't specify a username or can only specify a single username.  Believe it or not there are still a lot Windows 98 boxes in the world.  This way I can specify the username for them, always the correct username.

> 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.
> 

I haven't had any unexpected results with it in about about 4 years of use.  You guys rock.

> > 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').
> 

Your buggy by products are my awesome features.

> 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.
> 

Jerry, I couldn't care 2cents about whether or not its "real" share mode security.  In fact honestly I've always known and looked at this as a kind of very cool little gimmick Samba provides which I find very useful, and so I use it.

> No offense :-)
> 
> 
> 
> cheers, jerry

Cheers.

Tom