What are the access rights and privileges that control changing ownership of an object?


Changing the ownership of an object (typically a file) is not difficult in principle: You call the SetNamedSecurityInfo function with the new security descriptor.

The hard part is getting to that point. (Thanks to John, a colleague in security, for correcting an earlier draft of this entry.)

If you have WRITE_OWNER access on an object, then you can change the owner of the object to yourself (or to any SID in your token that has the SE_GROUP_OWNER attribute): you can take ownership. However, you cannot change the owner to somebody else: you cannot give ownership to another person. Doing that would allow you to violate quota restrictions.

Imagine if this were possible, that you could change the ownership to something that you aren't a member of: Your account is at its disk quota. No problem, you just find somebody who isn't over quota (like Fred in Accounting) and take some of your biggest files and set their owner to Fred. This causes the disk space to be charged to its new owner Fred, without Fred even knowing that it has happened to him. If you put the file in a directory that Fred doesn't have access to, poor Fred will start getting "You are over disk quota" messages and have no way of finding this evil file that you charged to him. It's like stealing somebody's library card and checking out books with it.

In order to set the owner to somebody else, you need to assert SeRestorePrivilege, which by default is assigned to administrators and backup operators. Backup operators need to be able to set the owner to somebody else because restoring its security descriptor is an important part of the process of restoring a file from backup.

But what about SeTakeOwnershipPrivilege? That privilege is assigned to administrators, and it lets you act as if you had WRITE_OWNER access (but not SeRestorePrivilege) to everything. With SeTakeOwnershipPrivilege, you can take ownership of any file, but you can't assign it to somebody else.

And then there's the mysterious CREATOR_OWNER SID, described in a Knowledge Base article as well as in a blog entry by Larry Osterman. The important thing to remember is that granting CREATOR_OWNER SID to an object after it has been created doesn't actually grant anything to the creator or owner. Read the linked articles for more details.

Comments (11)
  1. Dr Pizza says:

    MS used to try to deny that Administrators could even do this, and made it impossible from the GUI (I think even in Win2K you can’t give ownership).

  2. Anonymous says:

    Unfortunately Unix/Linux allows root users to assign files to other users. One one or two occasions one of our customers got "quota reached" errors, which even broke his website. The problem was that one of the admins had unzipped a daily backup from the backup folder; but forgot to delete it afterwards.

    The tar.gz file was owned by root, but the files inside the archive were not. Thus, the user had suddenly used twice the amount of data. Spiffy!

  3. Dean Harding says:

    How else does one restore a backup of a user’s home directory?

    By being a member of the "Backup Operators" group.

    I agree that things are different in the UNIX world compared to the Windows world, but I think Windows got it right in this case.

  4. Anonymous says:

    I find the ability for the root user to assign ownership to be crucial for system administration of UNIX systems. I can’t speak for win32, I admin it but the only win32 server we have (an old NT4) just runs an old DB server so it hardly counts.

    UNIX assumes the root user knows what they’re doing, and can be trusted with the power assigned to them. This isn’t always a good idea, especially in the modern world. There’s work going on to move toward more limited admin priveleges by default, but the full power available to the root user is unlikely to go away – because you do need it sometimes.

    How else does one restore a backup of a user’s home directory?

    For other users, absolutely, "gifting" ownership is a bad idea. Older UNIXes used to permit it, but thankfully that’s gone now.

    Remember that the UNIX root user is *not* the same thing as the win32 Administrator. If you log in as root and work as root, especially in a GUI, you’re widely considered a blithering idiot. Most modern UNIXes won’t even let you get a GUI login as root. Instead, you temporarily "become root" (think "run program as" in win32, kind of) to perform tasks your normal priveleges will not permit you to do. This is intended to limit the working priveleges of the admin so they only use their full powers when required. It’d be nice to be able to have a "safe admin" as well… but we’re not quite there yet.

    In this case, I blame the admin. Failing to be aware of quotas on a system you run is just dumb. I don’t see how an OS can protect against stupid administrator errors (on a real server, not a client OS, where the admin actually needs to do serious work sometimes) without causing more problems. If you let the admin delete and move user files, it makes little sense to me to prevent them from assigning ownership as well.

  5. Anonymous says:

    I recently ran up against all sorts of difficulties with this in setting up a Win2k3 system. I had created some files as Administrator while setting up the system, but I wanted them in my normal-user home directory once I got everything set up. And so, expecting it to work like other Windows systems I’m used to, I simply moved the files (as Administrator) into the directory where I wanted them.

    Then I found out that I couldn’t do anything with them when I was logged in as the normal user. Nor, when logged in as Administrator, could I give them to my User account.

    Eventually, I think I ended up passing them to a shared drive on another computer and back, or something like that, in order to "launder" the owner names off them. Certainly there has to be a better way, but I couldn’t find it….

  6. Anonymous says:

    This also reminds me of a permissions thing that I recently came up against in Win2k3. I was installing a text editor which tends to keep its preferences in a .ini file in its "Program Files" subdirectory. When I installed the program, I discovered that unless I ran it as Administrator, it wouldn’t save any preferences from one session to the next — for some reason, when I ran it as a normal user, it wasn’t updating the .ini file. As a normal user, I was however able to edit the .ini file <i>in the text editor</i> and save it, and the changes would be loaded when I closed and reopened it.

    The only thing that I could figure was happening was that there was some way of setting permissions such that I was allowed to manually save a file under "Program Files", but that the program couldn’t automatically save things there. Is that possible? Are things actually set up that way?

    If that’s what was really going on, I’d be very interested if you’d write up a bit of description of how that all works.

    (Also, how would I go about setting the permissions in that directory so that things would work properly? This program had an option to save settings in the registry rather than the .ini file, but that’s not exactly a general solution to the problem!)

    Thanks!

  7. Anonymous says:

    Certainly there has to be a better way, but I couldn’t find it

    A better way would be to logon as administrator, grant your user account full control over the files, then logon as yourself and take ownership.

  8. Anonymous says:

    There are different permissions for being able to modify an existing file, and being able to create new files within a directory.

    It might be the text editor went about saving its settings by deleting and replacing the existing settings file, which could fail, while editing it yourself would only be modifying the existing file which would succeed.

    Basically there is no difference between what you as a user can do and what a program you run can do.

  9. Anonymous says:

    One of the biggest security problems in assigning ownership to someone else has nothing to do with quotas. If I can create a file and assign ownership to that person, then not only can I affect their quota (as previously mentioned), but I can potentially create an executable that will run using the assignee’s permissions level. A malicious user would have lots of fun with this one.

  10. Anonymous says:

    I haven’t studied the source code, but there is this utility to do exactly the change in ownership:

    http://wwwthep.physik.uni-mainz.de/~frink/chown/readme.html

    I used it back on Windows 2k and it worked fine.

  11. Anonymous says:

    Guys, there are several programs for this. I’ve blogged them in the past. One from MS itsownself: http://adminfoo.net/node/82

    And there’s SETACL from http://setacl.sourceforge.net/. Not to mention Alex Frink’s chown, which works pretty well too. Finally we move to payware: the folks at smallwonders.com make a few handy tools in this realm. I remember using this for massive ‘give ownership’ operations we ran during a company and domain reorganization nearly a decade ago (all users got new accounts, so changing ownership was a necessity).

    Back in the GUI, Paul Lebidinsky got it right – that method has been possible sine NT days. And Win2003 has a direct ‘give ownership’ dialog in the permissions gui box.

    All are properly administrator-only to the best of my knowledge. (Being an admin, I haven’t gone out of my way to test them as a user!)

Comments are closed.