Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux General Discussion (http://www.linux-archive.org/archlinux-general-discussion/)
-   -   want to try systemd but need some advice (http://www.linux-archive.org/archlinux-general-discussion/708400-want-try-systemd-but-need-some-advice.html)

Kevin Chadwick 09-29-2012 11:37 AM

want to try systemd but need some advice
 
> 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)
__________________________________________________ _____________________

Rodrigo Rivas 09-29-2012 08:59 PM

want to try systemd but need some advice
 
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

Fons Adriaensen 09-29-2012 09:29 PM

want to try systemd but need some advice
 
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)

Matthew Monaco 09-30-2012 03:59 PM

want to try systemd but need some advice
 
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.

Tom Gundersen 09-30-2012 09:10 PM

want to try systemd but need some advice
 
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

Fons Adriaensen 09-30-2012 09:13 PM

want to try systemd but need some advice
 
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)

Fons Adriaensen 09-30-2012 09:50 PM

want to try systemd but need some advice
 
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)


All times are GMT. The time now is 10:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.