Rich access control lists

Posted Oct 21, 2015 16:23 UTC (Wed) by felixfix (subscriber, #242)
In reply to: Rich access control lists by niner
Parent article: Rich access control lists

Do I misunderstand you? Are you actually saying that because root and physical access can override any file permission security, get rid of file permissions?

Rich access control lists

Posted Oct 21, 2015 16:34 UTC (Wed) by niner (subscriber, #26151) [Link] (5 responses)

I honestly don't know how my comment can be interpreted in that way, but it obviously can :)
So, no, it absolutely was not meant in that way.

If you as an attacker want to circumvent file permissions and the way you do it is by booting a different kernel, no feature bit in the world can stop you. To boot the other kernel you either have physical access to the media, or at least root access to the machine. So the feature bit is completely worthless as protection.

File permissions are a security device in a running system. Once the system is not running anymore be it because the drives are removed or the system is rebooted, the security is gone. That's why we have disk encryption. Disk encryption won't help you if the attacker breaks into the running system. File permissions may. But disk encryption helps you where file permissions won't: with offline attacks.

Rich access control lists

Posted Oct 21, 2015 16:55 UTC (Wed) by bfields (subscriber, #19510) [Link] (2 responses)

Right, understood, but this is more something to keep administrators from shooting themselves in the foot, like warnings on rm -rf /, or -EBUSY on attempts to mount the same block device twice.

If you're mounting an ACL-protected filesystem on a multi-user system that isn't capable of enforcing them then there's a reasonable chance you're just making a mistake.

I assume there's some way to clear the flag if you still really want to do it.

Rich access control lists

Posted Oct 21, 2015 23:06 UTC (Wed) by neilbrown (subscriber, #359) [Link] (1 responses)

(off-topic tangent)
> -EBUSY on attempts to mount the same block device twice.

You are showing your age! It has been for many years that trying to mount an already-mounted block device simply creates a bind-mount.
You do get -EBUSY if you mount a block device on a directory where the same block device is mounted, but I think that is just to stop repeated "mount -a" from flooding the mount table.

Rich access control lists

Posted Oct 22, 2015 1:52 UTC (Thu) by bfields (subscriber, #19510) [Link]

You are showing your age!

Already??

It has been for many years that trying to mount an already-mounted block device simply creates a bind-mount. You do get -EBUSY if you mount a block device on a directory where the same block device is mounted, but I think that is just to stop repeated "mount -a" from flooding the mount table.

Sigh; I was paying attention to this, honest! Thanks for the correction.

Rich access control lists

Posted Oct 21, 2015 23:03 UTC (Wed) by smoogen (subscriber, #97) [Link] (1 responses)

You just have never system administered a system where the owner wanted everything 7777 root:root because file permissions are evil.. that was exactly the same argument on why he ( a PHD of many sciences ) didn't think any file perms were needed. [And I have heard it enough times that you can never tell if a person is wanting to get rid of them all or just with why this shooting you in the foot prevention isn't really good. ]

Rich access control lists

Posted Oct 22, 2015 0:15 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> You just have never system administered a system where the owner wanted everything 7777 root:root because file permissions are evil.
So pretty much every system out there?

XKCD explains that succinctly: https://xkcd.com/1200/

Rich access control lists

Posted Oct 21, 2015 16:35 UTC (Wed) by mjthayer (guest, #39183) [Link]

I could see sense in optionally allowing root to mount the file system read-only (or read-write for that matter), if it required them to add an "I really meant this" parameter. My understanding of the article is that this is not planned.