Hi, On 06/26/2014 14:33, Svante Signell wrote: > On Thu, 2014-06-26 at 14:03 +0200, Jean-Christophe Dubacq wrote: >> [ ⏰ 26/06/2014 12:05 ] [ ✎ Svante Signell ] >>> On Thu, 2014-06-26 at 11:59 +0200, Ansgar Burchardt wrote: >>>> On 06/26/2014 11:34, Thorsten Glaser wrote: >>>>>> No, it didn't work. You had to be root for operations as simple as >>>>>> shutting down the computer. >>>>> >>>>> Only on Debian. OpenBSD and MirBSD have: >>>>> >>>>> -r-sr-x--- 1 root operator 122716 Sep 10 2013 /sbin/shutdown* >>>>> >>>>> I never understood why Debian doesn't. >>>> >>>> Google says the operator group also has (read) access to raw disk devices. >>> >>> What about creating a unique group then, e.g. calling it it shutdown? >> >> So that students can do eg ssh mybuddymachine /sbin/shutdown ? > > Of course with the additional check that the students are logged in to > that box locally, did I forget to mention that?
And for that you need to keep track of sessions via something like systemd-logind, ConsoleKit, utmp or something else, whatever developers decide to use. Mostly they seem to settle on systemd-logind. So, we end with a system that works for both simple (single-user) and more complex setups (multi-user, multi-seat). The question then is: "I have a system that works for both simple and complex setups. Should I implement (continue to maintain) a second system that only works for simple setups?" Some upstreams have decided that they have not the resources and interest to maintain a second system; they end with a dependency on systemd. Sometimes they keep code for the old system, but don't write code to fallback to it at runtime. So one has to decide at build time which system to support. Maintainers might choose to enable the system that works both setups[1] -- again ending with a systemd dependency, but still working on *BSD where the alternative (less capable) system in chosen instead. [1] It might be possible to build two alternative versions like done with, for example, vim. But maintainers might choose not to do so for the same reasons upstream -- not enough resources and lack of interest of involved people. So, if people care about support for mechanisms that don't rely on systemd-logind and only support a subset of configurations, they need to join upstream projects. Just stomping with your foot does not work: sign up to maintain support for non-systemd setups and implement fallback code from one system to another where needed instead. > Another point is of course is that if you are locally connected to > your/somebody else's computer nothing is hindering you from pushing the > on/off button or pull the plug (except physically). Is shutting off a > computer really a problem, normally multi-available ones are always on? Shutting the system down is just one example: you can go on with access to audio devices and USB ports (and connected media) in multi-seat configurations and so on. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ac237f.7080...@debian.org