Hi, As stated on bug #6642 I'm only able to get/set quota with root user, with all other users (even the one into Domain Admins group and user listed in admin user parameter), I get a NT_STATUS_ACCESS_DENIED. I've an other version of samba installed (3.0.28a) and I'm able to get the info (and seeing the quotas in windows explorer) without any problems [2010/01/11 14:12:33, 5] smbd/uid.c:353(change_to_user) change_to_user uid=(0,1287) gid=(0,513) [2010/01/11 14:12:33, 4] smbd/vfs.c:753(vfs_ChDir) vfs_ChDir to /home/l-bigonville [2010/01/11 14:12:33, 10] smbd/nttrans.c:483(reply_ntcreate_and_X) reply_ntcreate_and_X: flags = 0x16, access_mask = 0x2019f file_attributes = 0x0, share_access = 0x3, create_disposition = 0x1 create_options = 0x0 root_dir_fid = 0x0, fname = $Extend/$Quota:$Q:$INDEX_ALLOCATION [2010/01/11 14:12:33, 10] smbd/open.c:3366(create_file_default) create_file: access_mask = 0x2019f file_attributes = 0x0, share_access = 0x3, create_disposition = 0x1 create_options = 0x0 oplock_request = 0x3 root_dir_fid = 0x0, ea_list = 0x(nil), sd = 0x(nil), create_file_flags = 0x1, fname = $Extend/$Quota:$Q:$INDEX_ALLOCATION [2010/01/11 14:12:33, 5] smbd/fake_file.c:87(is_fake_file) is_fake_file: [$Extend/$Quota:$Q:$INDEX_ALLOCATION] is a fake file [2010/01/11 14:12:33, 3] smbd/fake_file.c:116(open_fake_file) open_fake_file_shared: access_denied to service[l-bigonville] file[$Extend/$Quota:$Q:$INDEX_ALLOCATION] user[l-bigonville] [2010/01/11 14:12:33, 10] smbd/open.c:3508(create_file_default) create_file: NT_STATUS_ACCESS_DENIED [2010/01/11 14:12:33, 3] smbd/error.c:60(error_packet_set) error packet at smbd/nttrans.c(541) cmd=162 (SMBntcreateX) NT_STATUS_ACCESS_DENIED
Created attachment 5252 [details] Fix for master/3.5.0. Can you test this please, should fix the issue - checking : conn->server_info->utok.uid == 0 isn't the correct check to see if we're root anymore. As rpc_samr_nt.c does, the correct check is : geteuid() == sec_initial_uid() Jeremy.
Created attachment 5253 [details] Crrect fix for master/3.5.0. Arg. Got the sense of the test reversed :-). Only deny if geteuid() != sec_initial_uid() This one fixes it. Jeremy.
Comment on attachment 5253 [details] Crrect fix for master/3.5.0. I think this patch is ok, but I don't think it fixes the problem... Wouldn't root be still the only possible user?
IMHO all admins of a share should be able to manage that. What was the previous behavior? The test on 3.0.28a was: if (current_user.ut.uid != 0) {
In 3.5.x we have inside change_to_user(): uid = conn->admin_user ? 0 : vuser->server_info->utok.uid; So if a user is set as "admin user" then we are already uid zero, so this fixes the problem for members of "admin user". If we want to fix this for domain admins group as well then yes, more changes are needed. I'll look into it. Jeremy.
Ah, ok
Any news for this bug?
If the patch fixes your problem assign the bug to Karolin <ks@sernet.de> It will be included in 3.5.1 then.
Ok I will retest and let you know. And for a fix into the 3.4 branch?
Again, we're waiting on your feedback. Once you've confirmed I can create a back-port for the next 3.4.x. Jeremy.
I'm wondering, why not add new privilege: SeIncreaseQuotaPrivilege that would allow any user with it to change quotas on the system, or use already implemented one: SeDiskOperatorPrivilege?
tested with 3.5 and it doesn't seem to work with user listed in "user admins" failed tcon_X with NT_STATUS_ACCESS_DENIED cli_full_connection failed! (NT_STATUS_ACCESS_DENIED) [2010/03/15 18:25:49.884160, 1] smbd/nttrans.c:2245(call_nt_transact_get_user_quota) get_user_quota: access_denied service [l-bigonville] user [l-bigonville]
What actual status of this bug is now? Whether members of "Domain Admins" can edit user quotas in 3.5.8?
for comment #5 > In 3.5.x we have inside change_to_user(): > > uid = conn->admin_user ? 0 : vuser->server_info->utok.uid; > > So if a user is set as "admin user" then we are already uid zero, so this fixes > the problem for members of "admin user". Yes, we have already effective uid zero. But quota code checks for conn->server_info->utok.uid, which seems not changed to zero for admin users... Search the whole code for "utok\.uid" -- we can see that in a lot of places (fe. source3/smbd/file_acess.c) the code if (conn->server_info->utok.uid == 0 || conn->admin_user) { ... is used, whereas quota stuff performs: if (conn->server_info->utok.uid == 0) { ... only. > If we want to fix this for domain admins group Then it should be enough to use "admin users = "+DOMAIN\Domain Admins" (change DOMAIN to your domani name).
Great catch - thanks ! I'm fixing this for master/3.6.0 and will post a 3.5.x version of the patch here. Jeremy.
Created attachment 6375 [details] git-am fix for 3.5.next Can you test this in your environment ? If it works for you I'll get metze to review for 3.5.next. Jeremy.
Comment on attachment 6375 [details] git-am fix for 3.5.next Looks good to me
Karolin, please pick for the next release
Pushed to v3-5-test. Will be included in the next release. Closing out bug report. Thanks!