On Mon, Feb 10, 2014 at 4:52 AM, Samuli Suominen <ssuomi...@gentoo.org> wrote:
>
> On 10/02/14 00:43, walt wrote:
>> Recent threads about consolekit vs logind(systemd) have made me curious, so
>> I've been studying...
>>
>> A few of us have had recent problems with things like plugging USB sticks,
>> which once worked transparently but now require root privileges.
>>
>> I've discovered that my own such problems are caused by this:
>>
>> $loginctl show-session 1   (I have only one session, cleverly named '1')
>>
>> Id=1
>> Timestamp=Sun 2014-02-09 07:18:32 PST
>> TimestampMonotonic=389744251
>> VTNr=1
>> TTY=/dev/tty1
>> Remote=no
>> Service=login
>> Scope=session-1.scope
>> Leader=426
>> Audit=1
>> Type=tty
>> Class=user
>> Active=no   <=========================  should be 'yes'
>> State=online  <=======================  should be 'active'
>>
>> Users of consolekit, don't feel neglected.  You should try this instead:
>>
>> $ck-list-sessions
>> Session1:
>>         unix-user = '1001'
>>         realname = '(null)'
>>         seat = 'Seat2'
>>         session-type = ''
>>         active = FALSE    (correct because I'm ssh'd into a remote box)
>>         x11-display = ':0'
>>         x11-display-device = '/dev/tty2'
>>         display-device = '/dev/tty1'
>>         remote-host-name = ''
>>         is-local = FALSE
>>         on-since = '2014-02-09T22:00:10.750312Z'
>>         login-session-id = '1'
>>
>> Canek explained that the reason my session is not 'active' is that I'm
>> not using a Display Manager (gdm kdm lightdm), which talks to logind or
>> consolekit and vouches for my physical presence at the local keyboard.
>>
>> However, when I do the same thing on arch linux (as a virtualbox guest)
>> I see that my session (running gnome) is 'active' and I have no trouble
>> powering off the virtual machine as an unprivileged user.
>>
>> Any ideas how I can fix it?
>>
>> BTW, this helped me to understand some of the buzzwords I used above:
>>
>> http://www.freedesktop.org/wiki/Software/systemd/multiseat/
>>
>>
>
> sys-auth/pambase with USE="consolekit" or USE="systemd" brings in
> pam_ck_connector.so (ConsoleKit) or pam_systemd.so (systemd)
> is required in login to get the initial active session:
> ConsoleKit or systemd-logind starts during boot -> user logins to tty1
> -> PAM triggers pam_ck_connector.so or pam_systemd.so -> and now you
> have one
> initial session, second one is started after 'startx' and the
> login-session-id is the key knowing it's the same user now in X11,
> instead of console since
> it changes the first session inactive (since it knows you now started
> X11 and are no longer in console) and activates the newly started one in X11

Exactly.

> however display managers with *built-in* CK or logind support are
> special, and more straightforward and directly talk to CK or logind, and
> thus, work
> somewhat more easily by skipping many possible problems

Again, exactly.

> maybe you can somehow do it with GDM

Yes, you can, but you can also do it via startx passing vt01 (or
whatever) to Xorg.

> so that remote session shows
> active, i don't know about that, but what you can do is write your own
> polkit
> rules like:
>
> Put the following content to file: /etc/polkit-1/rules.d/51-local.rules
>
> polkit.addAdminRule(function(action, subject) {
>     return ["unix-group:wheel"];
> });
>
> Now users in group "wheel" should be able to do anything, this is also
> in "man 8 polkit"

I don't think that's a good idea. It's going to work, but it's like
killing flies with cannons, and perhaps a security risk.

More importantly, it's not necessary since X.org has built in support
for logind; you just need to pass to it the virtual terminal to use so
the user session it's shared in X11.

No need to configure anything, works out-of-the-box, and you don't
even need the root password. You just need to use startx this way:

startx -- vt01

(Or vt02, or vt03, etc.) And that's it. By the way, you can also
specify the seat for X.org with -seat seatX or whatever.

And that's the beauty of logind; it's getting support everywhere
(GNOME, polkit, KDE, Xfce, barebones X), and it frees us from
modifying permissions, or adding/joining groups, or creating policykit
rules, since it does the Right Thing™.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Reply via email to