Mastering POSIX File Capabilities

An anonymous reader passes along an IBM DeveloperWorks article on POSIX file capabilities, which have recently become available in the Linux kernel; they are expected in the mainline kernel by 2.6.24. POSIX file capabilities parcel out root user powers into smaller privileges. The article details how to program using file capabilities and how to switch on the ability of a system's setuid root binaries to use file capabilities.

Comments

Re:At last

[Anonymous Coward]

Nope, I don't think you read and/or understood the article. This has nothing to do with file permissions it affects what 'capabilities' the resulting process has when it is executed. As far as I know Windows does not have anything similar. As for NTFS style ACLs those have been around for a while, google for POSIX ACLs.

Not the correct comparison.

[Junta]

Linux has had filesystem ACLs for ages (arbitrary lists of people with sets of permissions above and beyond user/group/world permissions).

This is essentially a finer-grained setuid. I.e., before, the filesystem permission granularity was 'the /bin/ping program code is permitted to assume root privileges', because ping needed to do *one* thing that only root could do. Code in this position is generally thoroughly audited and such, but presume for a moment a user figured out a buffer overflow using some ICMP pattern that would cause ping to execute arbitrary code. If not written correctly, the results could be disasterous. If well written, the program code has dropped all but the capability it needed, but the kernel/permissions aren't forcing the issue so the code must be trusted.

Enter this mechanism. Now, you can *force* the issue in the filesystem permissions to never even possibly allow ping anything but what it needed. If ping was badly written to not drop any privileges, and a malicious user overflowed, he'd still only be able to create raw sockets, and nothing more.

This sort of complexity I'm not sure is dealt with in Windows (or how) I don't even know what may or may not need setuid to be a good example under their architecture. It certainly paves the way for future distributions to have a lot fewer setuid programs to worry about (though, on the flip side, programs with few enhanced capabilities may still be dangerous and yet be less obvious as it isn't setuid, file listing may have to be tweaked to reflect the kinda-setuid nature to leave awareness).

Unfortunately...

[Junta]

ls is not equipped (as far as I know) for displaying acls.

$ getfacl .
# file: .
# owner: ownaccount
# group: owngroup
user::rwx
group::r-x
other::r-x

That was default, reflecting:
drwxr-xr-x 2 ownaccount owngroup 4096 2007-12-23 12:28 .

$ setfacl -m mythtv:rw .
$ getfacl .
# file: .
# owner: ownaccount
# group: owngroup
user::rwx
user:mythtv:rw-
group::r-x
mask::rwx
other::r-x

And ls shows:
drwxrwxr-x+ 2 ownuser owngroup 4096 2007-12-23 12:28 .

Note the +. It's enough to indicate acl existance, but not more than that.