Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix file access rwx permissions are simple but tricky

igoro.pro

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Unix file access rwx permissions are simple but tricky

#51

Post by foresto »

saulpw wrote: 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…

> Do we really need multiple users for desktop unix?

I do, and not just for system services as mentioned by others.

I have separate user accounts for general desktop use, gaming, software builds, software testing, and a variety of containers.

Isolation is useful.

Re: Unix file access rwx permissions are simple but tricky

#52

Post by quotemstr »

saulpw wrote: 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…

You want every app of yours to be a different "user" so they can't access each other's data without arbitration. The term "user" is an unfortunate Unix inheritance. There's no reason that a single human (as he might on Unixes like Android or iOS) shouldn't have a hundred Unix "user" IDs at his disposal, one for each app.

Re: Unix file access rwx permissions are simple but tricky

#53

Post by quotemstr »

jesprenj wrote: post #19
0cf8612b2e1e wrote: post #10

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.

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 “root” on all my machines and I remove the username from PS1. /root is shorter than /home/a (:

Just change your home directory to /me. Who cares about /home?

As for permissions: on a single human machine, sudo is useful principally to introduce friction to random install scripts doing random things to my system. In day to day use, there's no reason for me to input my password just to install some Firefox snap or something.

Re: Unix file access rwx permissions are simple but tricky

#54

Post by remram »

Interesting, I was just diving into the permission system today. I was wondering if it was possible to delegate administration of a directory, e.g. give permission to some non-root user to delete files created by others in that directory.

Turns out it doesn't seem possible. Even if you use ACLs, whatever default ACL you set can just be removed from sub-directories by their respective owners. This seems like a big blind spot, unless I just missed something; all those groups, access lists, bits, and I can't even do that?

Re: Unix file access rwx permissions are simple but tricky

#55

Post by emmelaich »

teo_zero wrote: post #18

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…

I'd argue you could drop x as well. It's really an attribute not a permission, since you can copy a file without x then chmod +x it.

That fails for setuid files but that's a setuid thing not an x thing. It also fails I guess for executables that check argv[0] but probably not important.

Re: Unix file access rwx permissions are simple but tricky

#56

Post by emmelaich »

teo_zero wrote: post #18

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…

> owner can have less rights than the others.

Indeed it's funny that you can `sudo chown root regularfile` and you'll then be able to read it, since the group now applies not the user.

Re: Unix file access rwx permissions are simple but tricky

#57

Post by dataflow »

quotemstr wrote: post #49
dataflow wrote: post #47

Earlier quoted context omitted.

You could but it would induce corruption in programs. Programs expect I/O to fail much more often than they expect memory accesses to fail.

Programs using mmap have to be prepared for SIGBUS on mapped region access anyway --- consider the surprise removal (yanking out USB stick) case. That few programs, especially native code ones, bother to make themselves robust against this failure mode of mmap doesn't make it any less part of the mmap contract between the kernel and userspace.

Contracts are one thing, reality is something else though.

Re: Unix file access rwx permissions are simple but tricky

#58

Post by emmelaich »

fuzztester wrote: post #33
inetknght wrote: post #28

Earlier quoted context omitted.

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.

It's pretty common for people the misuse the terminology but not the semantics.

Re: Unix file access rwx permissions are simple but tricky

#59

Post by emmelaich »

remram wrote: post #54

Interesting, I was just diving into the permission system today. I was wondering if it was possible to delegate administration of a directory, e.g. give permission to some non-root user to delete files created by others in that directory. Turns out it doesn't seem possible. Even if you use ACLs, whatever default ACL you set can just be removed from sub-directories by their respective owners. This seems like a big bli…

Yeah AFAIK you'd have to make a frontend to `rm` and execute with sudo. I've done this a few times.

Relatedly, and possibly helps you implement half of the scheme. You can make a dropbox[0] style directory by removing the search (x) attribute and having some program continuously scan and rename dropped files to some random string.

[0] dropbox in the traditional meaning of course, not the cloud storage

Re: Unix file access rwx permissions are simple but tricky

#60

Post by wruza »

c-hendricks wrote: post #29
wruza wrote: post #25

Earlier quoted context omitted.

I have to clean my grandmas tablet every time my nieces come and screw it up by installing games, moving icons around and setting who knows what.

Right, but you're not logging in to a separate account for that.

A separate account for kids would make this cleanup unnecessary. They don’t want to screw it up for her, they just do what they think will help with their activities.
Post reply on HN