I want my UNIX groups back

The breakage of permissions under recent PolKit/logind is flabbergasting. They have completely subverted UNIX groups/permissions in a difficult-to-unbreak way. And I get cheerful little update messages saying things like “You no longer need to be in the camera group to use cameras” like it’s a fucking feature (and they’re lying; they mean users logged in locally no longer need to be in the camera group – remote users still need it). If I want a user to have access to some hardware on a machine, I’ll give it permissions. If I don’t, I probably don’t for a reason. Let’s talk use cases: perhaps you would like to hide the camera from a kid’s user. Or you would like to check on something with the camera attached to your remote machine. Or work a music player via SSH. Or generally use the resources on the machine you bothered to log into remotely because why the fuck else would you have logged in there? Every one of those is now more complicated to accomplish. Adding a facility to enable/disable permissions for remote or local users might be reasonable, but just fucking breaking groups for a couple use cases no one uses is moronic. (Seriously, Fast User Switching keeps coming up as a rationale for breaking things. Has anyone, ever used fast user switching on one of the platforms that supports it? There are usually more computer-like-devices than people in a household now, it isn’t relevant.)

Can someone please come up with a straightforward way to just noop all the PolKit bullshit so I can have my UNIX box back from the FreeDesktop assholes?

This entry was posted in Computers, General and tagged , , , . Bookmark the permalink.

10 Responses to I want my UNIX groups back

  1. Sarah says:

    I don’t even know about this logind stuff is, I just liked the anger in this post.

  2. MageFantastic says:

    It’s becoming clear that the people that want to use their machine in the UNIX way are going to have to either switch to something like Slackware or move to one of the *BSDs, most likely NetBSD. The only reason that I haven’t done so is that the *BSDs do not support full disk encryption from bootloader to login prompt very well, and this is a must-have for me on a laptop.

  3. Or you could just, you know, configure your machine like that. It’s not like every household wants to learn how to be a sysadmin, but you clearly do, so the onus is on you to setup your machine as you see fit.

    Device ACLs and group stuff is really just a matter of udev rules. Just copy the rules from /usr/lib/udev/rules.d/ to /etc/udev/rules.d/ and make any customisations you want.

    Honestly, do you expect your generic distribution to be designed around the needs of people like you? Distros should (and thankfully do) cater for the common use case first, but still allow configuration quite happily outside of that for the more exotic setups.

  4. OpenBSD does have full disk encryption. With KMS, it would be the cat’s meow on your modern laptop. Without, it’s still perhaps the most consistent system with arguably the best development environment and quite a nice set of ancillary features.

  5. Jeff Read says:

    If permissions are granted by group, then anyone remotely logged in who belongs to that same can clobber your local instance or mess with your local devices.

    Think of login(1). When you log in, the system changes ownership of your login tty to you, so no one else can mess with your session. Well, systemd-logind is a natural extension of login(1) to other devices such as video and audio hardware, USB thumbdrives, phones, and cameras, etc. Simple permission grants using group assignments may work on your box, but they do not generalize to all use cases in a way that isn’t prone to bugs and race conditions.

    And this is why the community is standardizing on systemd: it is designed to do the correct thing in all cases. And once it is the standard, things will work the same across all distros.

    • pappp says:

      The point is that you don’t log in to a system if you don’t want to use the local resources. There is no other reason to have an interactive session on a machine. logind is doing the wrong thing in every case except a single user physically sitting in front of a physically connected terminal, which, frankly, is not the average case for most things Linux is used for.

      • Jeff Read says:

        There are many cases in which you don’t want to give remote users access to local resources. You don’t want them to clobber your display, or mess with your audio, or whatever. They could be authorized to do these things while sitting at the console, but when they’re not you don’t want them messing with whomever is.

        Also, consider multiseat configurations. Each seat — display, keyboard, pointer — needs to be isolated, permissions wise, from all the others, so that two people can sit at and use the same machine without interfering with each other. Currently this kind of setup is *only* possible with logind; and logind is bound to be the only solution supported by upstream for session privilege isolation. Logind only *enhances* the kinds of privileges you can grant or withhold for individual login sessions. You can configure polkit to use group-based access if that’s what you really want.

        In the future, the concept of a virtual console terminal is bound to be removed from or deprecated in Linux. VTs are hacky and cause endless problems with mode switching; Wayland does a much better job of multiplexing the console. On a VT-less system, login(1) will be useless unless for some reason you have actual VDTs are attached. logind is login’s replacement.

        • pappp says:

          Multiseat is a red herring, we live in a world where it is devices per user, not users per device, it makes no sense to design for multiple physically connected terminals as a normal use case. It is a world where we have lots of connectivity, so many computers even casual users interact with are at the other end of an internet connection; remote users are a first-class concern.

          That logind is probably inevitable (and is, at least, less broken that the same people’s last effort at session management, ConsoleKit should never have been allowed to happen) is not equivalent to logind’s model being a good idea. The fact that polkit has been through two iterations of hideous user-hostile rule syntax, and all the distros ship defaults that are “just groups, but with random expectation-violating exceptions” tells me it just isn’t a good model. Nothing says “good design” like having to hunt through a couple different implicitly-hierarchical directories of barely-human-readable configs to find out what session or uaccess field is causing the hardware you know is connected to a remote machine to be hidden from the people who are supposed to be using it.

          The easiest example of a wrong assumption is that display devices are per-seat; GPUs have become co-processors, they’re becoming even more so, and designing your permissions model to treat them as a per-seat resource is at least as wrong as the VT model. Also, storage devices. Storage devices are not per user objects. There are on-disc permissions (and/or encryption) if you want that. They are not per seat devices, we’ve collectively abdicated all our data to cloud providers because of generations of foolish technologists making bad decisions that make it hard to use your own remote resources, we don’t need another iteration of that error.

          The existing hodgepodge of half-baked reverse engineered crap (and I mean that with the uttermost respect to the people who are writing them) and tenuously attached proprietary blobs makes me think the change in the Linux graphics layer is going to be a lot slower and more painful than some people are trying to claim. I was playing with Wayland on supposedly pretty well supported hardware the other day, and Haiku (To be fair, BeOS and Plan9 had most of the parts of what the future of computing should look like, and we are moving that way, just with terrible implementation) is ahead of a Linux box with Wayland/Weston in terms of having a working graphical environment.

          • Jeff Read says:

            I was referring to Wayland’s capability to multiplex the display — not necessarily be a “good” GUI like BeOS — but it looks like in the future, virtual consoles will be handled by systemd itself, not the kernel or Wayland.

          • Jeff Read says:

            Multiseat is a red herring, we live in a world where it is devices per user, not users per device, it makes no sense to design for multiple physically connected terminals as a normal use case.

            Having too many computers is a textbook literal first-world problem. There are still places in the world where computer equipment is expensive and very hard to come by. I hear stories about multiseat deployments in places like Brazil, serving several school kids with a single PC. Without a policy broker to set up ownership and permissions for the various seats, such a thing would not be possible. Right now the solution for that is systemd-logind.

Leave a Reply

Your email address will not be published. Required fields are marked *