[HN Gopher] Unix file access rwx permissions are simple but tricky
___________________________________________________________________
Unix file access rwx permissions are simple but tricky
Author : hyzyla
Score : 28 points
Date : 2024-08-15 20:16 UTC (2 hours ago)
(HTM) web link (igoro.pro)
(TXT) w3m dump (igoro.pro)
| saulpw wrote:
| 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 getting downvoted. Is it that offensive to
| question orthodoxy?
| eadmund wrote:
| Those multiple users could be used to implement sandboxing.
|
| And of course if one has a family then one might want accounts
| for Mom, Dad, Alice and Bob.
| saulpw wrote:
| The days of multiple family members using the same computer
| are long gone. Do you ever log into anyone else's
| desktop/laptop, or does anyone else ever log into yours?
| That's what I'm getting at.
| bigstrat2003 wrote:
| Yes, actually. My wife occasionally logs into my desktop
| and vice versa. But I take your point - it's far less
| common than it used to be, even if it does still happen.
| IcyWindows wrote:
| Yes, my children log into their own accounts to play games
| and/or do homework on the desktop computer with large
| monitors and good GPU.
| bloqs wrote:
| Depressingly i think sharing computers at least in the
| western world has become a thing of the past. At the very
| least, sharing your main form of computing.
| throwaway87483 wrote:
| We're sharing a computer as we speak.
| pjmlp wrote:
| Of course, nowadays even more so, unless users want to expose
| $HOME to the world.
| ratorx wrote:
| User is useful for isolation, not just between system and user,
| but also between different bits of the system. This is more
| useful on a server running multiple different services, but
| desktop software often has multiple services as well (although
| I can't think of an example right now).
|
| Groups are a bit more niche IMO, but without groups there is no
| real other way to express the constraint of thing X uses file
| A,B, thing Y uses file B,C - how can they share the data
| without making things globally accessible or duplicating it.
| That's probably a less frequent occurrence, but does come up
| (but again more on servers than desktop).
| stefan_ wrote:
| Except they all already use the insanity that is SELinux
| because they found users and groups too limiting for their
| "guaranteed to break production at runtime" security scheme.
| People suggesting we need user accounts for isolation are a
| generation behind the engineers tasked with papering over
| security issues.
| ratorx wrote:
| SELinux is definitely over-engineered, but it's not for the
| same problem as file permissions. File permissions are
| purely for files, whereas increasingly Linux does not
| nicely follow the philosophy of everything being a file.
| Once you have non-file resources and capabilities, it is
| very tempting to attempt to generalise permissions beyond
| them and if you attempt to bolt it on, you'll get something
| like SELinux.
|
| I wouldn't say file permissions are necessarily outdated.
| You can get pretty far using something like systemd
| capabilities, which are much more supplementary to the
| existing Unix file permission model.
|
| The very best approach to this IMO is OpenBSD pledge and
| unveil. Managing the permissions as part of the binary
| itself is much less fragile, although it doesn't have
| exactly the same threat model. It also has the added
| benefit of temporal safety, which I'm not sure you can do
| with SELinux.
| 0cf8612b2e1e wrote:
| 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.
| jesprenj wrote:
| 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 (:
| 0cf8612b2e1e wrote:
| That requires faith in software not making hard coded
| assumptions about filesystem structure. Something which I
| am not prepared to do. How much software still cannot
| respect XDG?
| DSMan195276 wrote:
| Users are still useful for isolation, many daemons on your
| system are likely running with different UIDs (or could be
| configured to do so) to increase isolation between them and the
| rest of the system.
|
| Groups are a bit less useful (IMO), but still good for handing
| out access to things like device files. If a daemon should have
| permissions to XYZ /dev file then you add them to the group
| associated with it.
| arp242 wrote:
| It seems to me that stuff like iwd, ntpd, udevd, bluetoothd,
| dhcpcd, etc. etc. each running as a different user is pretty
| desirable. Every system works like this, including Windows.
|
| The most obvious reason for this is so that a security problem
| in one of these daemons won't be able to read your Firefox
| cookies, install a rootkit, and stuff like that.
| stefan_ wrote:
| No, a group called "wheel", "dialout" and users "irc games uucp
| list gnats mail news" are essential to the Linux desktop. The
| only cruft facing the Linux desktop today is the unification of
| bin and sbin.
| pdonis wrote:
| _> I get that you want some division between system and user_
|
| Which, as others have pointed out, means various system
| services running as other users (since you don't want them
| running as your user, and you also don't want them running as
| root). On most desktop unix machines that only one person uses,
| that's the main use case for multiple users (and for multiple
| groups since groups are used to manage access to various
| functions like printing, usb sticks, cd-roms, etc.).
| wruza wrote:
| 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.
| 1oooqooq wrote:
| The nicer things are suid a guid.
|
| suid is to run things as another user without passwords. Mostly
| used for root access today and ignored for anything else. I
| personally think that's a missed oportunity when they added the
| unshare/namespace/capdrop stuff... would have been so nice if the
| interface to containers was a freaking simple 'suid as this lowly
| user' for a userland api. anyway.
|
| and guid ON DIRECTORIES, are so that users can save files in a
| groups that then others can also update. So you can have
| `/srv/http/htdocs userA webmasters -rwxswx---`
|
| then there's umask which may help or get in the way. and getfacl
| et al.
|
| overall it's a mess that covers many usecases after you've been
| initiated.
| teo_zero wrote:
| 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, permissions could be coded in just 6 bits: 2 to express
| who can read, 2 for who can write, and 2 for who can execute.
| Each set of 2 bits would be interpreted this way: 00=nobody,
| 01=only owner, 10=group or owner, 11=everybody.
___________________________________________________________________
(page generated 2024-08-15 23:00 UTC)