How does the Unix file privilege system differ from that of Windows?

Question

Related question: How does the Linux file system/organization differ from Windows?

I am somewhat familiar with how privileges work when it comes to files and directories - each entry has an owner and group property that represent the owner of the file and the group that the owner belongs to (correct me if I'm wrong).

How does this differ from the organization of permissions in the NTFS filesystem on Windows? What advantages does Unix's permission system have over NTFS?

Solution 1

NTFS has Windows ACEs. Unix uses "mode bits" on each file.

On NTFS, each file can have an owner, and zero or more Windows access control entries (ACEs). An ACE consists of a principal (users and groups are principals), a set of operations (Read, Write, Execute, etc.) and whether those operations are allowed or denied. Files can have many ACEs. Other objects in Windows other than files can have ACEs as well, such as registry entries, printer objects, and other things. All ACEs are taken into account when a file operation occurs. Deny takes precedence over allow.

Windows ACEs support inheritance where you can set an ACE for a directory and have it automatically propagate to lower level directories.

Files in Unix have an owning user (owner) and an owning group (owner-group). There are three fixed "principals" which are owner, members of the owning group, and everyone else (a.k.a world). For each principal there are three "bits" which cover read, write, and execute abilities. (these have different meanings for directories than files, see this). These bits determine who can perform what operations. This is called the file's mode and is built into the file (there are no separate ACEs).

Most of the time you are concerned with the "world" permissions, i.e. setting all three bits to 0 for "world" means no one who isn't the owner or group-owner can do anything with the file. Unix permissions only work on the filesystem, but since most objects appear as files you can use permissions to restrict access to disks, printers, etc. Unix permissions are simpler but more "coarse." Unix permissions do not support inheritance and will not affect lower level directories, with the exception of execute permission for directories (I think) which causes newly created files to assume permissions of the directory (but doesn't affect currently created files).

Traditionally Unix files have a single owner and a single owner-group. There are extensions to Linux that add ACEs to files in similar fashion to Windows.

Unix's advantage is only that a simpler system is usually easier to understand and secure, and speed since the filesystem doesn't have to fetch ACEs in addition to inodes when opening files.

Solution 2

One thing that's quite different is that "executable" is a permission under Linux/Unix, not based on the file's name or extension.

This is an advantage over Windows, in that on Linux you can ensure something doesn't get executed by removing executable permissions. No magic extensions matter at all. This is probably one reason why traditional file viruses got exactly nowhere on Unix and Linux.

Comments

[Random832]

That's setgid permission for directories, and it makes files inherit the owner-group, not the permissions.

[Hello71]

@George: One thing you need to remember is that group is NOT the group of the owner, it is separate. See chgrp(1).

[LawrenceC]

@Random832: Thanks for the clarification.

[Patches]

Windows actually does have an executable permission, although they defeat the purpose by setting it by default.

[Shadur]

Most distributions nowadays include support for extended Access Control Lists (ACLs) compiled into the various available filesystems by default. The name of the software package needed to access and modify these is generally called acl or facl or something similar, with the two programs named setfacl and getfacl to modify or retrieve access control list settings.

[RMA]

Extensions don't matter on windows either.

[dbush]

@Logan: Actually, they do have significance on Windows. The file extension determines what program(s) can be used to open it as well as indicating to explorer what type of file it is so that thumbnails can be generated. In the latter case, that could potentially exploit a bug that exists in the thumbnail generator and therefore could compromise a system.

[RMA]

@George The same applies to a graphical file manager with a buggy thumb nail previewer on any operating system. My point was that CreateProcess doesn't give two hoots if your program ends in .exe (and this is easy to see by running a program from cmd.exe), but it does indeed care about the execute bit.

[dbush]

@Logan: Ah, I see. But that certainly isn't because Windows performs some sort of advanced analysis of the file's header - it simply tries to link and load the file and reports a failure if it cannot.

[RMA]

@George, right just like Unix (unless you want to start arguing about whether looking for a shebang is "advanced" or not). I just wanted to make it clear that the file extension has nothing to do with the security model. If you mark an executable non-executable on Windows it has the same effect it does on a unix.