Bug 7080 - Quota only shown when logged as root
Quota only shown when logged as root
Status: RESOLVED FIXED
Product: Samba 3.4
Classification: Unclassified
Component: VFS Modules
3.4.5
Other Linux
: P3 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-29 14:39 UTC by Laurent Bigonville
Modified: 2011-04-07 19:09 UTC (History)
3 users (show)

See Also:


Attachments
Fix for master/3.5.0. (506 bytes, patch)
2010-02-01 17:55 UTC, Jeremy Allison
no flags Details
Crrect fix for master/3.5.0. (506 bytes, patch)
2010-02-01 18:00 UTC, Jeremy Allison
metze: review+
Details
git-am fix for 3.5.next (2.79 KB, patch)
2011-04-05 21:18 UTC, Jeremy Allison
metze: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Bigonville 2010-01-29 14:39:58 UTC
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
Comment 1 Jeremy Allison 2010-02-01 17:55:34 UTC
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.
Comment 2 Jeremy Allison 2010-02-01 18:00:32 UTC
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 3 Stefan Metzmacher 2010-02-08 05:27:34 UTC
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?
Comment 4 Laurent Bigonville 2010-02-08 06:31:24 UTC
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) {
Comment 5 Jeremy Allison 2010-02-08 11:40:12 UTC
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.
Comment 6 Stefan Metzmacher 2010-02-08 12:12:18 UTC
Ah, ok
Comment 7 Laurent Bigonville 2010-02-26 06:10:40 UTC
Any news for this bug?
Comment 8 Stefan Metzmacher 2010-02-26 06:29:55 UTC
If the patch fixes your problem assign the bug to Karolin <ks@sernet.de>
It will be included in 3.5.1 then.
Comment 9 Laurent Bigonville 2010-02-26 06:52:32 UTC
Ok I will retest and let you know.

And for a fix into the 3.4 branch?
Comment 10 Jeremy Allison 2010-02-26 10:32:59 UTC
Again, we're waiting on your feedback. Once you've confirmed I can create a back-port for the next 3.4.x.

Jeremy.
Comment 11 Hubert Kario 2010-03-02 17:12:46 UTC
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?
Comment 12 Laurent Bigonville 2010-03-15 12:29:33 UTC
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]
Comment 13 Dmitry Butskoy 2011-04-05 16:20:58 UTC
What actual status of this bug is now?

Whether members of "Domain Admins" can edit user quotas in 3.5.8?
Comment 14 Dmitry Butskoy 2011-04-05 17:37:06 UTC
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).
Comment 15 Jeremy Allison 2011-04-05 18:27:18 UTC
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.
Comment 16 Jeremy Allison 2011-04-05 21:18:46 UTC
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 17 Stefan Metzmacher 2011-04-06 06:46:12 UTC
Comment on attachment 6375 [details]
git-am fix for 3.5.next

Looks good to me
Comment 18 Stefan Metzmacher 2011-04-06 06:46:39 UTC
Karolin, please pick for the next release
Comment 19 Karolin Seeger 2011-04-07 19:09:30 UTC
Pushed to v3-5-test.
Will be included in the next release.
Closing out bug report.

Thanks!