Live data from Hacker News

Unix file access rwx permissions are simple but tricky

igoro.pro

31–40 of 77 posts

Re: Unix file access rwx permissions are simple but tricky

#31
post #2

I've been wondering about this for awhile. Do we really need multiple users for desktop unix? I get that you want some division between system and user, to protect the user against themselves. And read-only files are similarly useful, if only because some devices are read-only. But do we really need user/group/other permissions for desktop unix? and all the complexity of groups, and euid, etc. Edit: not sure why I'm…

I feel like macOS had the right idea for desktop security, with a per-binary permissions model when it comes to accessing sensitive areas in $HOME.

I know this can be done in Linux using flat packs, snaps, and the like, but I would really appreciate if sandboxing could be done at a more fine grained level, without coupling sandboxing and distribution.

Re: Unix file access rwx permissions are simple but tricky

#32
post #2

I've been wondering about this for awhile. Do we really need multiple users for desktop unix? I get that you want some division between system and user, to protect the user against themselves. And read-only files are similarly useful, if only because some devices are read-only. But do we really need user/group/other permissions for desktop unix? and all the complexity of groups, and euid, etc. Edit: not sure why I'm…

It took me a shockingly long amount of time before I realized it was silly to have a username on my machines. I am the only person using this, why am I typing unnecessary cruft? Username switched to “a”, which ends up saving space in my home path and terminals.

lightdm brings up my username automatically, ~ is home. Are you saving much? That said, unix originals used three char usernames.

Re: Unix file access rwx permissions are simple but tricky

#33

It's counterintuitive that the owner can have less rights than the others. Honestly, I've never seen it put in practice in any real-world file system. Incidentally, this is also not very efficient: UNIX permissions as they are today require 9 bits, namely rwx for owner, rwx for group, and rwx for others. But in an alternative universe where owner's rights win over group's rights which win over others' rights, permiss…

Alas, you're missing some bits. Sticky bit in particular can be associated to each of those too. There's probably others that I don't remember off the top of my head. > It's counterintuitive that the owner can have less rights than the others I completely concur. I've also never seen it used in the wild, but I know about it because I stumbled upon it more than once building scripts and not being careful about what fl…

>Sticky bit

Interestingly, I have come across some people who confuse the sticky bit with the setuid bit.

Re: Unix file access rwx permissions are simple but tricky

#34
I attended a Tanenbaum lecture once where he talked about how silly it was that nothing happens if permissions are reduced for a file while some other user/process has an open handle to it, and this is something Linux doesn't care to handle and MINIX does (or perhaps just that a kernel/filesystem should handle it, and few do -- I don't recall exactly). Surely an edge case (logging? what else? I never keep files open for too long), but I thought it was an interesting one.

You can test this in Bash: userA does cat>/tmp/newfile (assuming a chmod or relaxed umask so /tmp/newfile is created with permissions 0664), userA types in lines of text every few seconds, userB does tail -f /tmp/newfile and watches lines appear, then userA does chmod 600 /tmp/newfile, but userB can continue to tail -f /tmp/newfile and watch lines appear.

Re: Unix file access rwx permissions are simple but tricky

#35

It's counterintuitive that the owner can have less rights than the others. Honestly, I've never seen it put in practice in any real-world file system. Incidentally, this is also not very efficient: UNIX permissions as they are today require 9 bits, namely rwx for owner, rwx for group, and rwx for others. But in an alternative universe where owner's rights win over group's rights which win over others' rights, permiss…

This would also have the advantage of being cheaper to list out; instead of rw-r----- (0640), it would just be “gu-” (-, u, g, a for the four levels).

Re: Unix file access rwx permissions are simple but tricky

#36

Earlier quoted context omitted.

It took me a shockingly long amount of time before I realized it was silly to have a username on my machines. I am the only person using this, why am I typing unnecessary cruft? Username switched to “a”, which ends up saving space in my home path and terminals.

lightdm brings up my username automatically, ~ is home. Are you saving much? That said, unix originals used three char usernames.

Login from a terminal requires exact username, so I am saving literal seconds per day. just rolls off the keyboard.

Re: Unix file access rwx permissions are simple but tricky

#37
post #23
post #2

I've been wondering about this for awhile. Do we really need multiple users for desktop unix? I get that you want some division between system and user, to protect the user against themselves. And read-only files are similarly useful, if only because some devices are read-only. But do we really need user/group/other permissions for desktop unix? and all the complexity of groups, and euid, etc. Edit: not sure why I'm…

Yes, we really need users for desktops on all operating systems. Fundamentally limiting a computer to a single user is immeasurably idiotic and I wonder how one comes to that question even. Somehow it slipped in for phones and that’s a big part of why they suck. E.g. you can’t have work, life, private/second life and tmp/trash accounts on your phone and have to either carry multiple devices or mix lives together.

You can though! Stock Android supports multiple users. Just enable it in settings

Re: Unix file access rwx permissions are simple but tricky

#38

I attended a Tanenbaum lecture once where he talked about how silly it was that nothing happens if permissions are reduced for a file while some other user/process has an open handle to it, and this is something Linux doesn't care to handle and MINIX does (or perhaps just that a kernel/filesystem should handle it, and few do -- I don't recall exactly). Surely an edge case (logging? what else? I never keep files open…

Yes, it's the equivalent of "perimeter security" in networking. Once you are inside accessing a resource (connected to a network node or reading from a file descriptor in the kernel), you don't lose that access.

Re: Unix file access rwx permissions are simple but tricky

#39

I attended a Tanenbaum lecture once where he talked about how silly it was that nothing happens if permissions are reduced for a file while some other user/process has an open handle to it, and this is something Linux doesn't care to handle and MINIX does (or perhaps just that a kernel/filesystem should handle it, and few do -- I don't recall exactly). Surely an edge case (logging? what else? I never keep files open…

How would you want memory-mapped files to work, if permission changes affected open files?

Re: Unix file access rwx permissions are simple but tricky

#40
post #2

I've been wondering about this for awhile. Do we really need multiple users for desktop unix? I get that you want some division between system and user, to protect the user against themselves. And read-only files are similarly useful, if only because some devices are read-only. But do we really need user/group/other permissions for desktop unix? and all the complexity of groups, and euid, etc. Edit: not sure why I'm…

I feel like macOS had the right idea for desktop security, with a per-binary permissions model when it comes to accessing sensitive areas in $HOME. I know this can be done in Linux using flat packs, snaps, and the like, but I would really appreciate if sandboxing could be done at a more fine grained level, without coupling sandboxing and distribution.

That's what SElinux is for. However, you might have to write your own policies, the usual ones that most distributions ship are tailored to the server usecase. Android also uses SElinux for that kind of access restrictions, but works somewhat different form "normal" desktop linux.
Post reply on HN