[Samba] Re: security=share, who needs it ?
craigwhite at azapple.com
Fri Mar 17 15:58:45 GMT 2006
On Fri, 2006-03-17 at 09:12 -0600, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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.
More information about the samba