First of all, Linux does have ACLs – POSIX ACLs, which allow setting the permission bits for any number of users and groups. (Patches for RichACL, ACLs very similar to NFSv4 and WinNT, have been submitted repeatedly, but not merged yet.)
Ownership can be used as a sort of safety escape – the owner can always change the object's ACLs, even if the change would be denied otherwise, for example, if someone accidentally removed all ACL entries or denied all changes to everyone. (On Linux only the owner or superuser can change a file's ACLs, since there is no separate "change ACLs" permission.)
Another use of file ownership, on both Windows NT and Linux, is for determining whose quota should the file be counted on, if disk quotas are in use.
Yes.
This all depends on who creates the file on the destination. Try this:
$ touch some_file
$ ls -l some_file
-rw-r--r-- 1 userA userA 0 Apr 9 17:44 some_file
$ ls -ln some_file
-rw-r--r-- 1 501 501 0 Apr 9 17:44 some_file
So in my example, userA's numeric uid is 501.
Now transfer it, logging into the remote system as userB:
$ scp some_file userB@computerB:
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 userB users 0 Apr 9 17:50 some_file
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 1743 20 0 Apr 9 17:50 some_file
As you see here, userB created the file, and userB has numeric uid 1743. See also how the timestamp changed?
This is the default behavior of scp. You can preserve attributes though by using scp's "-p" option. This only preserves timestamp and permissions -- and importantly, not ownership. This might be exactly what you're looking for:
$ scp -p some_file userB@computerB:
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 userB users 0 Apr 9 17:44 some_file
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 1743 20 0 Apr 9 17:44 some_file
Note that besides scp, there are many different ways of creating files on remote machines -- NFS, FTP, WebDAV... these will behave in different, but similarly predictable ways. Let's not get carried away though -- you asked about scp.
(OT note, you actually created the file with 754 permissions! rwx=111=7, r-x=101=5, r--=100=4 – you see, r, w and x are bits in an octal word where r=4, w=2, x=1. That's why you'll see references to octal in relation to permissions. Thanks ernie for the correction!)
Best Answer
I have explained this in a blog post http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/ but it is also explained below.
When a file is copied, it has to create a brand new file and assign it a new set of permissions, so it gets the permissions from the parent folder as you know.
When a file is moved to another volume, what actually happens is that it is copied to the new volume and the old file is deleted. So the same process is repeated as above as it is a new file again and needs permissions set.
When the file is moved within the same volume, nothing really happens (at the disk level). It just changes the logical path location of the file. The actual data and physical file on the disk hasn't been touched or changed. Ever noticed when you move a 5GB file to another folder on the same drive, it is done almost instantly? This is why, because it actually hasn't moved but the pointer to where the file logically exists has changed. As it was not modified in any way, the permissions don't change also.
This is the reason for this behaviour.
Edit: Something I forgot to mention... The MS article isn't entirely accurate. MS quote:
The above quote only applies to objects that have been given EXPLICITLY defined sec permissions (turn inheritance off). As mentioned in my comments, it is all about keeping the ACL entries as efficient as possible. Consider the following example:
To keep the explanation simple, let's say you have a folder set to allow users modify rights only. Below this, there're thousands of files and none of them have explicit permissions set. It isn't very efficient to create ACLs for each file as they are exactly the same perms so it sets ONE ACL entry for the folder. This next bit is very IMPORTANT to understand; the files themselves have NO ACL PERMS. So when you move any of these file into a new folder in the same volume, MS claims the perms move with it (as above quote). Ask yourself this....how? There were no perms on the file in the first place to move across. This is actually incorrect and I just tested it now to confirm it. Let's say the destination folder you are moving the file to has perms to allow the everyone group modify rights only. Well since the file has no ACL directly, it inherits the ACL of the parent folder. This means the perms have changed from users modify (old folder) to everyone modify (new folder).
Notice the difference?? This time around, moving a file to another folder in the same volume actually has changed the perms, something MS says it doesn't do. Have I just found a mistake in MS documentation since 2000 lol??
Now look at the same scenario when using explicit permissions. If you set explicit permissions on a file within this folder (inheritance turned off) which, for example, denies users read access, it now creates A NEW ACL entry specifically for this file. Now when you move the file to a new location, it has an ACL entry directly related to it. In this case, moving a file to a new location in the same volume RETAINS its permissions (as MS claims)!