Package: samba Version: 3.0.24-6etch9 Severity: important Hi,
It appears that once you set a Samba server to be a primary domain controller that authenticates via a back-end LDAP server, it can no longer serve as a meaningful file server, because the 'valid users' setting simply doesn't work any more. It works on the normal Sambas which are set to use 'security = domain' with the Samba PDC, but not on the controller itself, for some reason. This behaviour may not be a bug in itself (I don't have any idea about the motivation, I suppose it could be sensible), but it is not documented in the manual page or the HOWTO, and the code doesn't warn me that the 'valid users' setting was ignored intentionally (if it has). It allows for information disclosure (shares that are accessible to the wrong users, even though you set them not to be), so it's a security problem, really. But I've kept the bug at a non-RC severity because I'm unsure of the reasoning, and because this isn't a particularly common setup, I guess. I'm not sure what's happening there, really... the smbd/service.c:575 check succeeds where it shouldn't. Annoyingly enough, you have to up the general debug level to 10 to get anything useful out of smbd/share_access.c:user_ok_token(). Even then, it doesn't show anything much: [2008/04/03 13:42:09, 10] smbd/share_access.c:user_ok_token(229) user_ok_token: share nagios is ok for unix user joy [2008/04/03 13:42:09, 10] smbd/share_access.c:is_share_read_only_for_token(271) is_share_read_only_for_user: share nagios is read-only for unix user joy The else cases of the lp_invalid_users(snum), lp_valid_users(snum) and lp_onlyuser(snum) should have DEBUG(20, ...) messages, because this way I don't really know if it's those NULL comparisons which have failed, or if the problems were the token_contains_name_in_list() checks within them. Now I'd have to edit the code, recompile and test it on a production PDC :/ I'll have to go reproduce it in a lab setting... Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]