Bug 286 - user-level access control only works as root
Summary: user-level access control only works as root
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control (show other bugs)
Version: 3.0.0preX
Hardware: All Linux
: P1 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-11 13:02 UTC by Dariush Forouher
Modified: 2005-11-14 09:24 UTC (History)
0 users

See Also:


Attachments
log.smbd snapshot (59.08 KB, text/plain)
2003-08-13 11:35 UTC, Dariush Forouher
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dariush Forouher 2003-08-11 13:02:43 UTC
Samba version : CVS from 11-08-2003

Tested with Windows 98 SE vanilla

Defining permissions on a share via user-level access control only
works if I'm logged in as root.


This is a log snapshot when logged in as an ordinary user:
[2003/08/11 21:14:14, 4]
rpc_server/srv_lsa_hnd.c:find_policy_by_hnd_internal(162)                      
                         
  Found policy hnd[0] [000] 00 00 00 00 02 00 00 00  00 00 00 00 06 EB 37 3F 
........ .....ë7?                                   
  [010] 82 04 00 00                                       ....                 
                                                  
[2003/08/11 21:14:14, 5]
rpc_server/srv_samr_nt.c:access_check_samr_function(105)                       
                         
  _samr_lookup_domain: access check ((granted: 0000000000;  required:
0x00000020)                                                 
[2003/08/11 21:14:14, 2]
rpc_server/srv_samr_nt.c:access_check_samr_function(114)                       
                         
  _samr_lookup_domain: ACCESS DENIED (granted: 0000000000;  required:
0x00000020)                                                 

And this is one when logged in as root:
[2003/08/11 21:38:05, 4]
rpc_server/srv_lsa_hnd.c:find_policy_by_hnd_internal(162)                      
                         
  Found policy hnd[0] [000] 00 00 00 00 02 00 00 00  00 00 00 00 9D F0 37 3F 
........ .....ð7?                                   
  [010] 07 2A 00 00                                       .*..                 
                                                  
[2003/08/11 21:38:05, 5]
rpc_server/srv_samr_nt.c:access_check_samr_function(105)                       
                         
  _samr_lookup_domain: access check ((granted: 0000000000;  required:
0x00000020)                                                 
[2003/08/11 21:38:05, 4]
rpc_server/srv_samr_nt.c:access_check_samr_function(109)                       
                         
  _samr_lookup_domain: ACCESS should be DENIED (granted: 0000000000;  required:
0x00000020)                                       
  but overwritten by euid == 0                                                 
                                                  
[2003/08/11 21:38:05, 2] rpc_server/srv_samr_nt.c:_samr_lookup_domain(2525)    
                                                  
  Returning domain sid for domain BRGTEST ->
S-1-5-21-1742692863-3551596981-1734739981                                      
     


Since even root seems to be missing SA_RIGHT_SAM_OPEN_DOMAIN right, I assume
that there must be something wrong somewhere else (this 'ACCESS should be
DENIED' looks like a workaround in my eyes).

regards
Dariush Forouher
Comment 1 Tim Potter 2003-08-11 18:03:26 UTC
This sounds like it is working as designed.  Only root or an administrator can
change the permissions of a share.  Does it work if you add the user to the
"admin users" smb.conf parameter?
Comment 2 Dariush Forouher 2003-08-11 23:57:40 UTC
Yes, putting an user into 'admin users' works as well.

But I think I should explain this a bit more detailed:
As an ordinary user, I can create new shares, close existing ones,
even change permissions on ones, that I've created as root before
(i.e. give some user who is already in the list additionally write-access)
The only thing that doesn't work is adding new list entries, which windows
denies with "the user list cannot be fetched. try again later".

I have to admit that I don't know how this is being managed unter WinNT, but I'd
be surprised if this is by design. (And IMHO at least Domain Admins should have
access to this, too.)

Another problem is that windows presents a blue screen everytime I connect to
this win98 machine (even by an `smbclient -L win98mach`). It makes no difference
if the user is in a access control list of a share or if he is not. Although I
don't know if these two problems are related, it makes user-level access
controls not very usable if every Domain User can bring down a win98 machine.

regards
Dariush
Comment 3 Tim Potter 2003-08-12 07:11:11 UTC
OK - thanks for the clarification.  I think I misunderstood what the problem was.  
Comment 4 Gerald (Jerry) Carter (dead mail address) 2003-08-12 20:30:54 UTC
Fixed by storing the access requested on the anonymous samr connect.
Restricted this to enum_domain|open_domain.  

Added become/unbecome_root() around pdb_enum_group_mapping()
enum domain groups samr call.
Comment 5 Dariush Forouher 2003-08-13 11:35:57 UTC
Created attachment 74 [details]
log.smbd snapshot

Yes, this fix solves the first problem.

But the blue screen still appears everytime I connect to this machine
("fatal exception at 0028:C0004D3F in VXD VMM(01)+00003D3F ...").

It also happens only if the authentication is succesfull.

This problem disappears if win98 is switched back to share-level access
control.

I've attached a level 10 debug log of smbd. It covers the time beginning at the
execution of `smbclient -L win98mach -Uuser%pass` until the blue-screen
appears.

regards
Dariush
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-02-07 08:41:32 UTC
originally reported against 3.0.0beta3.  CLeaning out 
non-production release versions.
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:21:21 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:24:48 UTC
database cleanup