Scp and file owner

The Microsoft Interix Unix subsystem (now retired) for its NT kernel dealt a little differently with user and group permissions than some others do:

User and group information is stored in the Security Access database. Both users and groups are stored in the same database, but group and user names must be unique; no group can have a user's name and vice versa. (This database replaces the /etc/passwd and /etc/groups files in UNIX.) Users and groups are created using the appropriate Windows methodology (User Manager, Active Directory Users and Computers, or Local Users and Groups) or with the Win32 net user command. (Example shell scripts to create and remove users are included in the directory /usr/examples/admin.) Users can belong to many groups.

Here are some more specific manual excerpts:

In Windows, either a user or a group can own an object. This is different from UNIX, in which only a user owns an object.

Windows identifies all users and groups internally by using a security identifier (SID). A hashing algorithm generates SID values that are unique; no two users or groups will have the same SID.

Users and groups that have permission to access an object are identified by their SID. All objects that can be secured by Windows have a discretionary access control list (DACL), which consists of separate entries called access control entries (ACEs). An ACE includes two important pieces of information: a user or group SID, and a description of how much access the individual user or group has to an object.

CHGRP

...Change the group ID for the file ... the user invoking chgrp(1) must belong to the specified group and be the owner of the file, or have appropriate privileges.

CHOWN

...The owner and group operands are both optional; however, one must be specified. If the group operand is specified, it must be preceded by a colon (:).

The owner can be specified by either a numeric user ID or a user name. If a user name is also a numeric user ID, the operand is used as a user name. The group can be either a numeric group ID or a group name. If a group name is also a numeric group ID, the operand is used as a group name.

For security reasons, the ownership of a file can be altered only by a process with appropriate privileges.

As I read it that means that if your user account belongs to a Windows group with sufficient privileges to modify a file's permissions that is owned by that group, then it is possible to effectively chgrp that file outside your user account's control. This amounts to lesser control than you might have with chown and explicit user:group parameters. In that context without the possibility of declaring user: and :group you never could achieve the same results as otherwise.

Here is a link to a detailed look at how Interix interacts with Windows ACLs with a focus on how such knowledge might apply to Samba file-systems on other Unix variants.

Here is a link to a now obsolete Solaris document describing the tunable rstchown which...

Indicates whether the POSIX semantics for the chown(2) system call are in effect...

Apparently, if the parameter is set to a value of 0...

...turning off POSIX semantics opens the potential for various security holes. It also opens the possibility of a user changing ownership of a file to another user and being unable to retrieve the file back without intervention from the user or the system administrator.

Such an option does not invalidate Solaris's POSIX conformance. Just that it is an option at all qualifies it as conformant:

Although all implementations conforming to POSIX.1-2008 support all the features described below, there may be system-dependent or file system-dependent configuration procedures that can remove or modify any or all of these features. Such configurations should not be made if strict compliance is required.

The following symbolic constants shall be defined with a value other than -1. If a constant is defined with the value zero, applications should use the sysconf(), pathconf(), or fpathconf() functions, or the getconf utility, to determine which features are present on the system at that time or for the particular pathname in question.

_POSIX_CHOWN_RESTRICTED

The use of chown() is restricted to a process with appropriate privileges, and to changing the group ID of a file only to the effective group ID of the process or to one of its supplementary group IDs.

The chown() system function - which is the documented system call made by both the chown and chgrp shell utilities - is specified to fail for numerous reasons. Among them:

EACCES Search permission is denied on a component of the path prefix.

ELOOP A loop exists in symbolic links encountered during resolution of the path argument.

EPERM The effective user ID does not match the owner of the file, or the calling process does not have appropriate privileges and _POSIX_CHOWN_RESTRICTED indicates that such privilege is required.

The behavior of granting permissions modification rights to non-root users has never been unique to Solaris, however. There is very excellent - if somewhat dated - coverage of Unix file permissions in this forum post in which the author states:

Originally, Unix allowed a file owner to give away a file. A file's owner could change the owner to someone else. There was no way for a non-root user to undo this operation... BSD [later] removed chown from non-root users ...[in part because]... it implemented disk quotas which could limit how much disk space a user could have in a filesystem... Naughty users could give away large files to sneek past the quotas.

Today, it is not easy to say if a non-root can chown a file. Many versions of Unix allow both behaviors...

Another good - and more recent - mailing-list post quotes this and continues:

The default with most OS's is for chown to be restricted to root only. And there is a consensus that it should stay this way for security considerations. If a non-root user does change the owner of a file and any execute bit is on, the SUID and SGID bits must be cleared. This may or may not happen with root.

I think that last paragraph says it nicely.

That article also references CAP_CHOWN to control that facility on Linux (that should only affect the POSIX_CHOWN_RESTRICTED behavior). There is also the CAP_FOWNER capability, that's a little different in behavior.

And as you point out in 2003:

Note that at least on HPUX, you can change the owner of your files (to root for instance) even if you're not a priviledged user...

...which depended upon a configuration setprivgroup parameter.

In any case in which a non-root user can manipulate file-permissions it is conceivable, as is mentioned in the rationale quoted in your question, that a user might chown a file which that user owns so that it is owned by another user. If the file's group ownership and the chowning user's groups do not align then the user would no longer be capable of modifying that file.

In this scenario chown then chgrp would fail as the user would no longer have permissions to alter that file's permissions, whereas chown user:group - so long as group is among the user's own - would succeed.

There are probably numerous other niche situations that might result similarly, which might include directory sticky and/or setgid bits, file-system and/or implementation-specific access-control lists. This thread is interesting, for instance. The countless permutations are far beyond my own feeble grasp - which is why this answer is wikied. If you're reading this, you believe it is worth improving, and you believe you know how - please do.

There is also extensive documentation on the various possible effects of file permissions, tree traversal, and symbolic links that might effect a similar failure with regards to -Recursive chown applications here:

From POSIX XRAT section headings Third and Fourth Domains :

Generally, users specifying the option for a file hierarchy traversal wish to operate on a single, physical hierarchy, and therefore symbolic links, which may reference files outside of the hierarchy, are ignored. For example, chown owner file is a different operation from the same command with the -R option specified. In this example, the behavior of the command chown owner file is described here, while the behavior of the command chown -R owner file is described in the third and fourth domains.

...There is a security issue with defaulting to a logical walk. Historically, the command chown -R user file has been safe for the superuser because setuid and setgid bits were lost when the ownership of the file was changed. If the walk were logical, changing ownership would no longer be safe because a user might have inserted a symbolic link pointing to any file in the tree. Again, this would necessitate the addition of an option to the commands doing hierarchy traversal to not indirect through the symbolic links, and historical scripts doing recursive walks would instantly become security problems. While this is mostly an issue for system administrators, it is preferable to not have different defaults for different classes of users.

...

In 4.3 BSD, chgrp during tree traversal changed the group of the symbolic link, not the target. Symbolic links in 4.4 BSD did not have owner, group, mode, or other standard UNIX system file attributes.

And from the POSIX chgrp page proper there is this which points to a possible incomplete -Recursive action, or at least to what used to be:

The System V and BSD versions use different exit status codes. Some implementations used the exit status as a count of the number of errors that occurred; this practice is unworkable since it can overflow the range of valid exit status values. The standard developers chose to mask these by specifying only 0 and >0 as exit values.

Yes, all files under /usr should be owned by root, except that files under /usr/local may or may not be owned by root depending on site policies. It's normal for root to own files that only a system administrator is supposed to modify.

There are a few files that absolutely need to be owned by root or else your system won't work properly. These are setuid root executables, which run as root no matter who invoked them. Common setuid root binaries include su and sudo (programs to run another program as a different user, after authentication), sudoedit (a companion to sudo to edit files rather than run an arbitrary programs), and programs to modify user accounts (passwd, chsh, chfn).

In addition, a number of programs need to run with additional group privileges, and need to be owned by the appropriate group (and by the root user) and have the setgid bit set.

You can, and should, restore proper permissions from the package database. If you attempt to repair manually, you're bound to miss something and leave some hard-to-diagnose bugs lying around. Run the following commands:

rpm -qa | xargs rpm --setugids --setperms