[arch-general] want to try systemd but need some advice
From reading the avaiable docs I'm not convinced this will be possible, in
Hello all, During the past days I've been reading the sytemd manpages, and I'm more or less prepared to reconfigure one the systems I manage to use systemd. The main thing that scares me off is the 'consolekit style' login management of systemd's logind. In particular the following (from <http://www.freedesktop.org/wiki/Software/systemd/multiseat>): * A session is defined by the time a user is logged in until he logs * out. A session is bound to one or no seats (the latter for 'virtual' * ssh logins). and * Note that logind manages ACLs on a number of device classes, to allow * user code to access the device nodes attached to a seat as long as the * user has an active session on it. In the context I'm working in the whole 'seat' and 'session' thing, as far as I can understand it, doesn't make much sense. An absolute requirement for the system I'd want to test systemd on (and for many others I manage) is that there should be *no* difference at all between a 'local' login and one via ssh. Whatever a user is allowed to do or access should not depend on how he/she logs in, but only on his/her unix login and group membership. Root can do all he wants, normal users are as restricted as possible, and any exceptions to that are configured via /etc/sudoers and nothing else. In particular there's no place for polkit or anything similar here. I'd want things to be configured that way 'once and for all', meaning that a) I'm not really looking forward to having to do this for each and every device or command, and b) that a routine system update (a frequent enough event on an Arch system) must not be able to modify this policy. particular since the docs concerning logind are rather incomplete (where are those ACLs defined for example). And 'ping Lennart if you need more info' as suggested, is not really a sustainable solution IMHO. So my question is: a) is it possible to configure a system as I want it, and b) if yes, how ? TIA, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
In particular there's no place for polkit or anything similar here.
I'd want things to be configured that way 'once and for all', meaning that a) I'm not really looking forward to having to do this for each and every device or command, and b) that a routine system update (a frequent enough event on an Arch system) must not be able to modify this policy.
I can't help with systemd but this is getting harder with initscripts even too on linux, but atleast it's almost guaranteed to be possible and easyish with scripted rc. Do you have polkit installed as you may want to make sure it isn't or remove it's rights, letting it error may pollute your logs but may also prevent any potential timeouts from dependent or expectant packages.
From reading the avaiable docs I'm not convinced this will be possible, in particular since the docs concerning logind are rather incomplete (where are those ACLs defined for example). And 'ping Lennart if you need more info' as suggested, is not really a sustainable solution IMHO.
I approached the polkit dev with similar concerns asking how I can be sure what rights are granted and giving a blatant example of the inadequate documentation. He picked out the parts of my email suggesting OTHERS were wondering about RedHats motives (being mainly a support company now) for the difficulty of configuration and insulted me. In my opinion, he picked that part as an insult to him because he knew his software was for software devs rather than users or admins and I had raised difficult problems he didn't want to answer and which only applied to a small proportion of users. This situation is silly as a default security stance is by definition overly permissive and all security software should be completely transparent in it's permission granting to be taken seriously. Your task should be simple and final but unfortunately I have to wish you good luck. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Sat, Sep 29, 2012 at 9:52 PM, Fons Adriaensen <fons@linuxaudio.org>wrote:
Hello all,
During the past days I've been reading the sytemd manpages, and I'm more or less prepared to reconfigure one the systems I manage to use systemd. The main thing that scares me off is the 'consolekit style' login management of systemd's logind. In particular the following (from <http://www.freedesktop.org/wiki/Software/systemd/multiseat>):
* A session is defined by the time a user is logged in until he logs * out. A session is bound to one or no seats (the latter for 'virtual' * ssh logins).
and
* Note that logind manages ACLs on a number of device classes, to allow * user code to access the device nodes attached to a seat as long as the * user has an active session on it.
In the context I'm working in the whole 'seat' and 'session' thing, as far as I can understand it, doesn't make much sense.
An absolute requirement for the system I'd want to test systemd on (and for many others I manage) is that there should be *no* difference at all between a 'local' login and one via ssh. Whatever a user is allowed to do or access should not depend on how he/she logs in, but only on his/her unix login and group membership. Root can do all he wants, normal users are as restricted as possible, and any exceptions to that are configured via /etc/sudoers and nothing else. In particular there's no place for polkit or anything similar here.
I'd want things to be configured that way 'once and for all', meaning that a) I'm not really looking forward to having to do this for each and every device or command, and b) that a routine system update (a frequent enough event on an Arch system) must not be able to modify this policy.
From reading the avaiable docs I'm not convinced this will be possible, in particular since the docs concerning logind are rather incomplete (where are those ACLs defined for example). And 'ping Lennart if you need more info' as suggested, is not really a sustainable solution IMHO.
So my question is: a) is it possible to configure a system as I want it, and b) if yes, how ?
Well, you can disable the registering of systemd-logind sessions by deleting the lines with "pam_systemd.so" from the files /etc/pam.d/*. Not sure if that will be enough, or even wise. And now that you are into it, you could delete also the "pam_ck_connector.so" lines and see if it makes a difference. HTH -- Rodrigo
On Sat, Sep 29, 2012 at 10:59:45PM +0200, Rodrigo Rivas wrote:
Well, you can disable the registering of systemd-logind sessions by deleting the lines with "pam_systemd.so" from the files /etc/pam.d/*. Not sure if that will be enough, or even wise. And now that you are into it, you could delete also the "pam_ck_connector.so" lines and see if it makes a difference.
Thanks for the advice, but so far I have not installed anything, and I will only do so if and when I'm convinced that I will be able to configure the system as I want it. Which is nothing special since it has been working exactly like that for the past few years and with absolutley minimal reconfiguration effort from my side. And also because it's not a toy but something I depend on for my income. I'm perfectly prepared to put some effort into migrating to systemd, but I'm not prepared to 'fight' it in order to get what I want. If systemd is half as superior as it is claimed to be, then some manpage, or wiki, or an experienced user should be able to tell me what to do, without ifs and maybes. So far that is not the case, but I hope for the best. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On 09/29/2012 03:29 PM, Fons Adriaensen wrote:
On Sat, Sep 29, 2012 at 10:59:45PM +0200, Rodrigo Rivas wrote:
Well, you can disable the registering of systemd-logind sessions by deleting the lines with "pam_systemd.so" from the files /etc/pam.d/*. Not sure if that will be enough, or even wise. And now that you are into it, you could delete also the "pam_ck_connector.so" lines and see if it makes a difference.
Thanks for the advice, but so far I have not installed anything, and I will only do so if and when I'm convinced that I will be able to configure the system as I want it. Which is nothing special since it has been working exactly like that for the past few years and with absolutley minimal reconfiguration effort from my side. And also because it's not a toy but something I depend on for my income.
I'm perfectly prepared to put some effort into migrating to systemd, but I'm not prepared to 'fight' it in order to get what I want. If systemd is half as superior as it is claimed to be, then some manpage, or wiki, or an experienced user should be able to tell me what to do, without ifs and maybes. So far that is not the case, but I hope for the best.
Ciao,
Your login sessions from the display manager, virtual terminal, and ssh will all be very similar (if not identical) if you have the same settings in /etc/pam.d/{<DM>,login,sshd}. Btw, it seems like you're more concerned with logind than systemd, and pam_systemd.so would probably be better named pam_logind.so. That said, all of this seat an session management that consolekit, and now logind are doing, imo, makes these different logins more homogeneous because it explicitly defines concepts like session and seat. If you're willing to put in some time, then why don't you install simple system to a VM and make sure everything works as you expected? Alternatively, all of this work that Tom Gunderson (and others) have done recently allows you to switch between initscripts and systemd at boot time =) Systemd is superior to sysvinit in its design (my opinion). It also does a lot (maybe not so unixy, but lets see where this goes). However, it is still very young so it's difficult to get a lot of answers on google (google always spellchecks systemd->system...), find the correct manpage, find mini-howtos, etc. But hang in there, its functionality and presentation are being polished continuously. Along those lines, you're going to get a lot of ifs and maybes because the behavior is still in flux. This is in part do to upstream being very open to input from other projects.
On Sun, Sep 30, 2012 at 09:59:17AM -0600, Matthew Monaco wrote:
Your login sessions from the display manager, virtual terminal, and ssh will all be very similar (if not identical) if you have the same settings in /etc/pam.d/{<DM>,login,sshd}.
That may very well be true, but would it solve the problem ? Assume there are two ssh logins and a 'local' one. If I understand things correctly that would be three 'sessions', and only one of them can have any particular 'seat' and be 'active' at the same time. So as long any device is assigned to a single seat, at least two of those logins would be excluded from using it. And in the scenario you describe it's not even obvious which ones that would be. The only solution I see is that access to devices would not depend at all on logins etc. as is the case for a 'traditional' unix-like system. Which means that logind should not meddle with device ACLs etc. And my question is really if it can be configured to behave in that way. I really have no clue, the docs I've found so far are absolutely uninformative about that.
Btw, it seems like you're more concerned with logind than systemd, and pam_systemd.so would probably be better named pam_logind.so. That said, all of this seat an session management that consolekit, and now logind are doing, imo, makes these different logins more homogeneous because it explicitly defines concepts like session and seat.
That is true. I've no doubts at all that as an init system, or more generally as the 'top level supervisor', systemd is superior to the old initscripts and the traditional init process. It's the way UNIX should go. Purely _as a design_, and ignoring its current implementation limits, only upstart looks even better, but that's another story. I also like the way systemd makes writing and deploying daemons a lot easier and simpler, in particular because some of my work as a developer depends heavily on those. But _as a package_ systemd does more than just replace initscripts. It sort of 'sneaks in' the seat/session based security management, which is no longer optional as it was before. And I really have my doubts about that. It makes sense in a 'corporate' environment where many people could be using the same HW; also in a 'family' environment where you'd want some 'parental control' and avoid your IT-savvy kids blowing up your system every week. OTOH, for a really 'personal', i.e. single user system it is irrelevant, and in those situations where security is much more a matter of activity specific team dynamics than of central control, it could become a real PITA. And all my use cases ATM are of the latter kind. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sat, Sep 29, 2012 at 9:52 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
(from <http://www.freedesktop.org/wiki/Software/systemd/multiseat>):
The documentation of logind could indeed be better. Hopefully the manpage systemd-logind(5) will provide more complete information in the future.
An absolute requirement for the system I'd want to test systemd on (and for many others I manage) is that there should be *no* difference at all between a 'local' login and one via ssh. Whatever a user is allowed to do or access should not depend on how he/she logs in, but only on his/her unix login and group membership. Root can do all he wants, normal users are as restricted as possible, and any exceptions to that are configured via /etc/sudoers and nothing else. In particular there's no place for polkit or anything similar here.
Do I understand correctly that you simply want to disable systemd setting ACL's on your device nodes?
I'd want things to be configured that way 'once and for all', meaning that a) I'm not really looking forward to having to do this for each and every device or command, and b) that a routine system update (a frequent enough event on an Arch system) must not be able to modify this policy.
Makes sense.
From reading the avaiable docs I'm not convinced this will be possible
Assuming I understand you correctly, what you want is possible.
(where are those ACLs defined for example).
/usr/lib/udev/rules.d/70-uaccess.rules
So my question is: a) is it possible to configure a system as I want it, and b) if yes, how ?
The way the ACL's work is that the active session on a given seat is given access to every device node that is tagged with "uaccess" and the correct seat name by udev. To make sure no device nodes are tagged in this way, simply put an empty 70-uaccess.rules file in /etc/udev/rules.d. This means that the corresponding rules file in /usr/lib will be ignored, and the files under /etc are not touched during upgrades. If this is not entirely what you want to do, there are several other options, but assuming I understood you correctly I believe this is the least intrusive one for your purpose. Cheers, Tom
On Sun, Sep 30, 2012 at 11:10:36PM +0200, Tom Gundersen wrote:
Do I understand correctly that you simply want to disable systemd setting ACL's on your device nodes?
That is indeed my main concern. In particular, audio devices should be available to whoever is a member of the 'audio' group, and USB devices to the 'storage' group if that applies, or to some other group if they are anything else (e.g. musical keyboards, MIDI controllers etc.). All of this should be absolutely independent of who's logged in and how.
I'd want things to be configured that way 'once and for all', meaning that a) I'm not really looking forward to having to do this for each and every device or command, and b) that a routine system update (a frequent enough event on an Arch system) must not be able to modify this policy.
Makes sense.
By 'not be able' I mean that normal updates should not have that effect even if in theory they could. I appreciate pacman's habit of leaving a .pacnew and let me deal with it instead of instantly modifying things :-)
Assuming I understand you correctly, what you want is possible.
(where are those ACLs defined for example).
/usr/lib/udev/rules.d/70-uaccess.rules
So my question is: a) is it possible to configure a system as I want it, and b) if yes, how ?
The way the ACL's work is that the active session on a given seat is given access to every device node that is tagged with "uaccess" and the correct seat name by udev. To make sure no device nodes are tagged in this way, simply put an empty 70-uaccess.rules file in /etc/udev/rules.d. This means that the corresponding rules file in /usr/lib will be ignored, and the files under /etc are not touched during upgrades.
Many thanks for this info, it's really what I hoped for.
If this is not entirely what you want to do, there are several other options, but assuming I understood you correctly I believe this is the least intrusive one for your purpose.
I'm always eager to learn more... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
participants (5)
-
Fons Adriaensen
-
Kevin Chadwick
-
Matthew Monaco
-
Rodrigo Rivas
-
Tom Gundersen