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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
