The traditional user/group system may be simple, but it is limited. For example, it fails when you have a multi-user desktop system when some people login in locally, and some people login in remotely. What should the permissions on on the camera be? And what about hotplugged USB devices? It's no longer possible to have a fixed device node with fixed permissions and fixed user group membership.
The same applies to suspend. The local user perhaps should or should not be able to suspend the machine. Presumably remote users should not be able to do so at all.
What about wireless network connectivity as the machine moves? Who should have permission to manipulate that?
If we did not have more a more complex dynamic permission system[1], some would be saying that modern Linux is outdated and unable to cope with the more modern reality of much more dynamic needs like this.
Instead, the article seems to be saying that it's become too complicated.
I wonder how often it happens that people connects remotely to a Linux PC with a camera. When I do it is because I ssh to another laptop of mine, maybe to shut it down after I lost the desktop (maybe the graphic card crashed). OK, we should support as many use cases as possible but it could be acceptable to tell people that if they want to setup a multiseat machine shared with strangers (students at school? They can get very creative) they disable mics, cameras and don't plugin dvds and usb drives. Servers usually don't have any of them. Finally, if you give somebody a sudo you accept that s/he can shutdown the system remotely, normal case for a server.
I also wonder how other OSes handle that, I'm looking at Windows and OSX. With VNC/RDP/Teamviewer/etc you get full access to the Windows desktop and all devices. I guess OSX has the same, plus sshd.
So, maybe supporting a fringe use case is making more common use cases more inconvenient?
On Windows there is the Group Policy. If your machine is domain joined, the group policy is controlled by the domain. A non-domain joined machine also has a policy, which can be edited using the "Local Group Policy Editor".
The policy contains items such as "Devices: Allow undock without having to log on" or "Deny access to this computer from the network" (user/group list).
A policy consists of a number of such settings. For instance you can set who can shut down the system, and who can do it from remote.
With Windows 8 came <a href="http://www.windowsecurity.com/blogs/shinder/microsoft-securi... access control</a> where access control lists (ACLs) now can include tests for type of device being used, network location etc. This can be used to disallow access to certain documents or applications from phones/tablets while allowing access for the same user as long as he/she uses a stationary device within the corporate network. Dynamic access control also takes most of the pain out of complex access control as it can decide access not just upon your security group membership, but also on other claims such as limits, department, organizational unit, local certificates etc.
> Finally, if you give somebody a sudo you accept that s/he can shutdown the system remotely, normal case for a server.
Sudo configs are configurable (as are default command aliases) to at least make this a deliberate decision, and not an accidental occurrence. You could also, in rare cases, just "whitelist" certain commands, although this is generally not that practical.
Sudo, is however, by definition, a dangerous tool. I try to make sure that everyone who has the right is aware of the responsibilities.
Windows and Mac both have their own privilege escalation, and shutdown commands, so there's nothing particularly different about their situations.
I wouldn't worry much about people whom I granted access to my computer, (though it could be worrisome if someone else got their hands on their credentials), I would worry about people who got access fraudulently. But that requires tighter security policies.
Regarding Windows, it's all explained on MS website (just a Google search away), and it seems quite potent, but a default consumer OS doesn't push for stringent requirements for each and every application being installed. It's up to the user to setup the adhoc policy, and hook up VNC to it, I guess. The good thing with application markets and distro supported package repositories is that in theory all this could be included in the package and verified for conformance by the repository maintainers.
The traditional user/group system may be simple, but it is limited. For example, it fails when you have a multi-user desktop system when some people login in locally, and some people login in remotely. What should the permissions on on the camera be?
The way this kind of thing was solved 20 years ago was that you could be given membership of some additional groups when logging in locally.
(The wart is that if you, say, opened the sound device when you were logged in to one of the lab workstations locally, you could pass that file descriptor to another process and keep it open after you'd logged out, and then use it to play Rob Zombie at full volume when some unsuspecting victim was by themselves in the lab at 2am).
A fragile and too complex to troubleshoot system is an unreasonable tradeoff to support these niche use cases. Find better solutions or live with the old level of service. I suspect the PR cost of having imperfect multiseat support is insignificant.
I don't understand why multiseat support keeps getting brought up in systemd-related discussions.
It seems to me like an entirely artificial problem, all I have ever seen is computers that are used by at most one user at a time and multi-user servers with no desktop whatsoever.
I literally can not think of a situation where the multiseat usecase is relevant, small SOC computers cost too little compared to buying extra graphics cards and USB hubs.
Best i can tell, it is because some military guys wants to be able to airlift one computer and a bunch of screens, keyboards and rodents into the field, yet make sure that only the spooks gets access to the top secret stuff that shows how much the war is going to the dogs.
Then again, i can't see how to fix that with software, other than blankly refuse to assign a device that goes away and comes back to a existing seat. Never mind trying to assign a whole new device. It seems to sprout edge cases all over, like trying to zoom in on a Mandelbrot.
In practice, the "camera" group should be added by the driver (or whatever) install script, or maybe by the OS installer. Adding the user to the "camera" group would usually be the job of a wrapper around /usr/sbin/useradd or other admin tools. Usually, I would expect the distro to set up permissions that are apropriat4e for their intended audience (i.e. desktop vs multiuser-server vs "other").
On my gentoo desktop, my user account is in many groups for this very reason:
$ grep pdkl95 /etc/group | cut -d: -f1 | sort | column
audio deskmsg plugdev sshpermit video
cdrom floppy portage usb wheel
cron games postgres users
davfs2 pdkl95 realtime vboxusers
Often, I find that when someone claims that the user/group system is too restrictive, they haven't considered simply adding more groups.
> login in locally
> login in remotely
You would use PAM(8) for this. One method would be to use pam_group(8), by putting something like this in the appropriate /etc/pam.d/ config file, such as /etc/pam.d/login
auth optional pam_group.so
...and configure /etc/security/group.conf (see group.conf(5)) with something like:
gdm; *; *; Al0000-2400; camera
This way, the people that login with gdm are added to the "camera" group. Again, this is something I would expect desktop-focused distros to setup, at least for the common stuff.
> wireless network connectivity as the machine moves?
That would be a local permission, generally, which would be covered by a setup similar to what I describe above. Even if the computer moves, it is still the logged in (possibly through a suspend) user that needs permission to configure a network interface.
> some would be saying that modern Linux is outdated
...and I would reply that those people probably need to spend some more time researching how to fully utilize the user/group system and PAM. While there are a few cases where the UNIX style of permission is insufficient, they are rarely encountered on a typical desktop or simple server. In the case of the common single-user laptop where the one user is also the "admin", there only granularity you need is a description of when they should be prompted to be become root, which is trivial using basic user/group permissions.
The same applies to suspend. The local user perhaps should or should not be able to suspend the machine. Presumably remote users should not be able to do so at all.
What about wireless network connectivity as the machine moves? Who should have permission to manipulate that?
If we did not have more a more complex dynamic permission system[1], some would be saying that modern Linux is outdated and unable to cope with the more modern reality of much more dynamic needs like this.
Instead, the article seems to be saying that it's become too complicated.
We can't have it both ways.
[1] http://www.freedesktop.org/wiki/Software/systemd/multiseat/