[arch-general] want to try systemd but need some advice

[Tom Gundersen]

On Sat, Sep 29, 2012 at 9:52 PM, Fons Adriaensen <fons at 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