Bug 3098 - Taking ownership of directories not possible
Taking ownership of directories not possible
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
3.0.10
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-14 07:54 UTC by Jan Roehrich
Modified: 2005-09-14 07:56 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Roehrich 2005-09-14 07:54:43 UTC
I'm using samba as a win2000 domain member and providing some files using
posix ACLs
 
My share configuration is like that:
 
[software]
        path = /srv/software
        public = yes
        read only = no
        printable = no
        group = root
        directory security mask = 0777
        directory mask = 0770
        create mask = 0660
        store dos attributes = no
        dos filemode = yes
        inherit permissions = yes
        inherit acls = yes
        hide unreadable = yes
 
but I discovered a strange problem: 
Using the windows native acl tool I'm able to take file ownership of each
file in my share but not of any directory. Error message is "access denied". The
directories all have the same acl like file (rwx for the group of the user I'm
trying with).
Comment 1 Jan Roehrich 2005-09-14 07:56:35 UTC
Jeremy Allison tried to explain the problem to me. I'm not very familar with the
inner technical aspects of samba so I'll only pass his message along:

Currently in Samba 3.0.20 root can change ownership to any user,
someone with SeTakeOwnershipPrivilege can change owner to themselves,
and someone with write permission to a file can change owner to
the current authenticated user if dos filemodes are set. It's 
probably the latter case that matters to you - which is why the
users can chown the files, but directories never have file write
permission, which is what is stopping them chowning directories.

In Samba 3.0.21 we'll be closer to windows semantics in that someone
with SeRestorePrivilege can change the file to any other user. It
doesn't take care of the directory case though.