Bug 8147 - changing owner to a group results in NT_STATUS_INVALID_OWNER
changing owner to a group results in NT_STATUS_INVALID_OWNER
Status: RESOLVED FIXED
Product: Samba 3.6
Classification: Unclassified
Component: Winbind
3.6.0rc1
All All
: P5 enhancement
: ---
Assigned To: Michael Adam
Samba QA Contact
:
Depends on:
Blocks: 10077
  Show dependency treegraph
 
Reported: 2011-05-18 16:16 UTC by Björn Jacke
Modified: 2014-11-04 11:34 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Jacke 2011-05-18 16:16:47 UTC
In Windows the owner can be a group SID, too, not only a user SID. When a client sets the owner to a group SID Samba returns NT_STATUS_INVALID_OWNER because in posix_acl.c line 1200 sid_to_uid fails with group sids. Several users reported problems due this limitation in the last years and it can be reproduced easily by setting the homepath of a user to a deep UNC path that does not (yet) exist using NT4 usrmgr. In the logs you get:

[2011/05/18 11:05:54.544583, 10] smbd/posix_acls.c:3851(set_nt_acl)
  set_nt_acl: called for file dummy/dnwaq
[2011/05/18 11:05:54.544607,  5] smbd/posix_acls.c:1191(unpack_nt_owners)
  unpack_nt_owners: validating owner_sids.
[2011/05/18 11:05:54.544625,  3] smbd/posix_acls.c:1208(unpack_nt_owners)
  unpack_nt_owners: unable to validate owner sid for S-1-5-32-544
[2011/05/18 11:05:54.544644, 10] smbd/open.c:3210(create_file_unixpath)
  create_file_unixpath: NT_STATUS_INVALID_OWNER
[2011/05/18 11:05:54.544669, 10] lib/dbwrap_tdb.c:100(db_tdb_fetch_locked)
  Locking key 01080000000000000E60
[2011/05/18 11:05:54.544687, 10] lib/dbwrap_tdb.c:129(db_tdb_fetch_locked)
  Allocated locked data 0x0xb824ceb8
[2011/05/18 11:05:54.544703, 10] locking/locking.c:552(parse_share_modes)
  parse_share_modes: delete_on_close: 0, owrt: Wed 18 May 2011 11:05:54 AM CEST CEST, cwrt: Thu 01 Jan 1970 01:00:00 AM CET CET, tok: 0, num_share_modes: 1
[2011/05/18 11:05:54.544749, 10] locking/locking.c:655(parse_share_modes)
  parse_share_modes: share_mode_entry[0]:  pid = 4258, share_access = 0x3, private_options = 0x1, access_mask = 0x100081, mid = 0x0, type= 0x0, gen_id = 1, uid = 1003, flags = 0, file_id 801:68600e:0
[2011/05/18 11:05:54.544770, 10] lib/dbwrap_tdb.c:42(db_tdb_record_destr)
  Unlocking key 01080000000000000E60
[2011/05/18 11:05:54.544799,  5] smbd/files.c:497(file_free)
  freed files structure 11088 (0 used)
[2011/05/18 11:05:54.544816, 10] smbd/open.c:3463(create_file_default)
  create_file: NT_STATUS_INVALID_OWNER
[2011/05/18 11:05:54.544835,  3] smbd/error.c:80(error_packet_set)
  error packet at smbd/error.c(160) cmd=160 (SMBnttrans) NT_STATUS_INVALID_OWNER

A limited hack to work around this would be to "set force unknown acl user" but a real fix for this would be good.
Comment 1 Jeremy Allison 2011-05-18 17:07:21 UTC
Please describe exactly how "a real fix for this" would work on a POSIX system.

Jeremy.
Comment 2 Björn Jacke 2011-05-18 18:01:27 UTC
as discussed with obnox and metze, this could be solved by a more sophisticated idmapping which allows sid<>uid mappings for groups SIDs. This is not an enhancement but rather a major bug as we refuse valid nt create calls with a misleading INVALID_OWNER errors.
Comment 3 Jeremy Allison 2011-05-18 18:18:23 UTC
Bjorn, this is the VERY DEFINITION of an enhancement. Please don't change the importance field again.

Jeremy.
Comment 4 Michael Adam 2011-06-21 13:25:52 UTC
(In reply to comment #3)
> Bjorn, this is the VERY DEFINITION of an enhancement. Please don't change the
> importance field again.
> 
> Jeremy.

Err, what is the very definition of an enhancement?
"Fix for a bug that has been around for very long..."

:-)

Cheers - Michael
Comment 5 Stefan Metzmacher 2013-04-30 06:25:48 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Bjorn, this is the VERY DEFINITION of an enhancement. Please don't change the
> > importance field again.
> > 
> > Jeremy.
> 
> Err, what is the very definition of an enhancement?
> "Fix for a bug that has been around for very long..."

Isn't the fix for this in 4.0 (and master), there we have support for IDMAP_BOTH.
The remaining problem is that not all backends support it yet.
Comment 6 Stefan Metzmacher 2013-08-29 06:23:18 UTC
This is not a blocker for 4.2
Comment 7 Karolin Seeger 2013-12-10 15:32:34 UTC
(In reply to comment #6)
> This is not a blocker for 4.2

Currently, this one blocks bug #10077.
Should it be removed or not?
Comment 8 Jeremy Allison 2013-12-10 23:53:43 UTC
Yeah I think it can now be removed as smbd supports IDMAP_BOTH.

Jeremy.
Comment 9 Stefan Metzmacher 2014-11-04 11:33:34 UTC
Should be fixed in 4.x.y