recentpopularlog in

kme : sothatswhy   1

GNU Core Utilities Frequently Asked Questions -
The GNU chown program will change the ownership if the operating system it is running upon allows it. If you can’t change file ownership then it is the operating system which is restricting you and not the chown program.

Actually, the GNU chown command does not know if this is the policy of the system or not. It calls the kernel system call chown() just like any other program (e.g. perl, ruby, etc.) If the OS allows it then it will change the ownership of the file. Different systems handle this differently. Traditional System V Unix systems allow anyone to give a file away to other owners. On those systems GNU chown does change the ownership of files.

But on most modern systems BSD semantics are followed and only the superuser can change the ownership of the file. The problem for documenting this is that GNU chown does not know which it will be running on. It could be one or it could be the other. Or it might even be running on a system without the concept of file ownership at all! This is really an OS policy decision and it is hard to track documentation to be different on different systems. But the documentation must be independent of operating system.

The reason an operating system needs to restrict changing ownership is mostly threefold.

A user can create files that they cannot remove. With the old semantics it was possible for normal users to create situations that only the superuser could fix, such as creating a non-writable directory of files and then giving the ownership away. Since they no longer own the files they can’t change them, nor can they remove them. This is commonly a problem when untaring files that other people created with restrictive file permissions. The new semantics avoid this problem entirely. Therefore most systems today have been changed to disallow giving file ownership away. But as noted it has not always been that way.
Additionally systems need to restrict who can remove files from system temporary directories such as /tmp. Otherwise anyone could remove any file there which might disrupt system processes. Some programs might even have security issues associated with this. Therefore modern systems set the ’sticky’ bit on /tmp. This is the ’t’ bit. On directories this prevents users from removing or renaming a file unless they own the file or directory. The reason this is important is that if chown is allowed then /tmp is another place that a file could be created by a user, chowned, and then could not be removed by the user. A sticky /tmp and a restricted chown policy go together. If you have one then you should have the other as well.
People have used this to avoid disk space quota restrictions. Give the file to someone either with disk quota to spare or without any quota restrictions, like root. You can always copy the files back and then you own them again. This effectively defeats any quota system if allowed. Also, you can deny someone else service with a denial of service attack by using all of their quota until they cannot create any files. You use up their quota by chowning files to them someplace where they cannot find them.
gnu  linux  coreutils  chown  permissions  unix  sothatswhy 
6 weeks ago by kme

Copy this bookmark:

to read