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)
