-----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 :-) cheers, jerry ===================================================================== I live in a Reply-to-All world. ----------------------- Samba ------- http://www.samba.org Centeris ----------- http://www.centeris.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEGtH0IR7qMdg1EfYRAkgrAKCxCsZTZXfL1PupBd+TJGgGoYQUJgCg8AQz 51NMmDiFzrgc7fvKQ8qCXQw= =OtcM -----END PGP SIGNATURE----- -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba