Re: "not authorised" doing various desktoppy things [and 1 more messages] [and 1 more messages]

[Josh Triplett]

On Tue, 17 Jan 2017 13:35:14 + Ian Jackson 
 wrote:
> [1] AIUI this is when your laptop suspends to RAM, but after a timeout
> or when the battery is low, wakes up so that it can suspend to disk.

Linux implements hybrid sleep by going ahead and writing the hibernation
image out, then suspending to RAM.  That makes it take longer to sleep,
but it doesn't have to wake up later on a timer (likely in an enclosed
bag).  If you wake it up while still suspended to RAM, it can wake up
fast and ignore the hibernation image; if it runs out of battery and
loses power, then when you power it back on it'll resume from the
hibernation image and still not lose state.

Re: "not authorised" doing various desktoppy things [and 1 more messages] [and 1 more messages]

[Ian Jackson]

Martín Ferrari writes ("Re: "not authorised" doing various desktoppy things 
[and 1 more messages]"):
> This seems to solve the problem for me, thank you very much! (And I hope
> you can get this in for stretch!)

Thanks to everyone for their reports.  This is very helpful.

Currently experimental has 10-3~exp2 which also has a patch from
Nikolaus Schulz to support hybrid sleep[1].  I don't use this myself
so reports on that would also be welcome.

I indeed intend to push this to sid in the next few days, with the
plan that it will be in stretch.

Thanks,
Ian.

[1] AIUI this is when your laptop suspends to RAM, but after a timeout
or when the battery is low, wakes up so that it can suspend to disk.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Stephan Seitz]

On So, Jan 15, 2017 at 04:43:11 +, Ian Jackson wrote:

I have just uploaded systemd-shim 10-3~exp1 to experimental.  I seems
to fix the problem for me.  Depending on feedback, I will upload this
to sid in the next few days.


Thank you very much. I don’t have problems either.

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Martín Ferrari]

On 15/01/17 13:43, Ian Jackson wrote:
> Ian Jackson writes ("Re: "not authorised" doing various desktoppy things [and 
> 1 more messages]"):
>> More news later today.
> 
> I have just uploaded systemd-shim 10-3~exp1 to experimental.  I seems
> to fix the problem for me.  Depending on feedback, I will upload this
> to sid in the next few days.

This seems to solve the problem for me, thank you very much! (And I hope
you can get this in for stretch!)


-- 
Martín Ferrari (Tincho)

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: "not authorised" doing various desktoppy things [and 1 
more messages]"):
> More news later today.

I have just uploaded systemd-shim 10-3~exp1 to experimental.  I seems
to fix the problem for me.  Depending on feedback, I will upload this
to sid in the next few days.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

tl;dr
  TYVM to Michael Biebl
  I intend QA upload of systemd-shim with Michael's wrapper

Michael Biebl writes ("Re: "not authorised" doing various desktoppy things [and 
1 more messages]"):
> Am 05.01.2017 um 19:56 schrieb Michael Biebl:
> > Then copy the attached wrapper script to /usr/lib/x86_64-linux-gnu/
> > and make it executable.
> 
> Obviously, the wrapper script should start systemd-shim.orig.

Well, I only previously glanced at this script.  I thought it was a
way to collect more information.  Now that I sit down to deal with
this problem properly, I discover that actually it fixes the problem!

Thank you very much (and I'm sorry now that I was a bit avoidant about
trying this, thinking that it would be part of a big and stressy
debugging and spelunking session).

Correct me if I'm wrong, but I think the right thing is probably to do
is ship this comaptibility workaround in stretch.  I looked on my
system and filesystems of type cgroup are not mounted anywhere else.

And I'm not sure what is using /sys/fs/cgroup/systemd but it doesn't
seem to be systemd-shim.  I guess then that this is something that
used to be done by one bit of systemd and is now done by another bit,
so that it now has to also be done by systemd-shim ?

So my plan is to do a QA upload of systemd-shim which includes a
variant of your wrapper script (perhaps with set -e added...).  I
looked at the code in systemd-shim and implementing this code in its C
code doesn't look very convenient.  (It's also possible that this
should be done in an init script but I haven't considered that
properly.)

I haven't decided whether to put give the wrapper the name
`/usr/lib/x86_64-linux-gnu/systemd-shim' as you did, or alternatively
whether to give it a new name and change the reference in
  /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service
Unless anyone has an opinion I'll do whatever is easier.

More news later today.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "not authorised" doing various desktoppy things

[Ian Jackson]

Martín Ferrari writes ("Re: "not authorised" doing various desktoppy things"):
> On 03/01/17 17:05, Ian Jackson wrote:
> > Recently, my nm-applet can no longer control my network-manager
> > daemon.  I get a message saying[1]:
> 
> Did you ever get to the root of this?

No.  I have been too busy dealing with bugs in my own packages.  I
lost an awful lot of time to the dgit corrupted commits bug :-/ and am
now very behind on almsot everything.

> I am having the same kind of problem (no way to control networking,
> removable media, power settings) and a similar set-up (sysvinit,
> lightdm, cinnamon). I have been experiencing these kind of problems for
> months, but usually they would go away after an apt-get upgrade. Not
> now, and I am afraid that we will ship stretch with this problem.

Indeed.  I may get some time tomorrow to look at this properly, but
please don't wait for me.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "not authorised" doing various desktoppy things

[Martín Ferrari]

On 03/01/17 17:05, Ian Jackson wrote:
> Recently, my nm-applet can no longer control my network-manager
> daemon.  I get a message saying[1]:

Did you ever get to the root of this?

I am having the same kind of problem (no way to control networking,
removable media, power settings) and a similar set-up (sysvinit,
lightdm, cinnamon). I have been experiencing these kind of problems for
months, but usually they would go away after an apt-get upgrade. Not
now, and I am afraid that we will ship stretch with this problem.


-- 
Martín Ferrari (Tincho)

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Adam Borowski]

On Fri, Jan 06, 2017 at 01:58:50PM +0100, Ansgar Burchardt wrote:
> > > Including access to devices (which X wants these days)?
> > 
> > That's just for ancient graphics cards (ie, with no KMS/DRM support)
> > without xserver-xorg-legacy, right?
> 
> logind is required for drivers using KMS and *not* the legacy suid
> wrapper, see /usr/share/doc/xserver-xorg-core/NEWS.Debian.gz.

Nope, I don't have systemd (and thus logind) on any of my non-virtual
machines, I don't have xserver-xorg-legacy either, yet X works fine.

I've just pulled out the oldest box I have in my junk pile (a pre-amd64
Pentium4 with Intel 82915G/GV/910GL), installed current X on it -- works
fine without logind.  Non-KMS stuff you need xorg-legacy for sounds ISAish.
On the other hand, hurd which has no KMS does need xorg-legacy.

> I think wayland does the same (I haven't used it though).

Me neither.

> So eventually alternatives should probably provide an alternative for
> this part of logind too.

I guess that "relies on logind" part is true only under systemd?  At least,
other VT manipulating tools like "open" run into permissions problem there
too.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ansgar Burchardt]

On Fri, 2017-01-06 at 07:48 +0100, Adam Borowski wrote:
> On Thu, Jan 05, 2017 at 12:19:08PM +0100, Ansgar Burchardt wrote:
> > With elogind do you mean https://github.com/wingo/elogind?  That
> > project doesn't look very active.
> > 
> > Is there any active project trying to reimplement the logind API? 
> 
> Consolekit2 for example; it suffers from being a fork of consolekit
> codebase though.

That one looks indeed still active.

> > Including access to devices (which X wants these days)?
> 
> That's just for ancient graphics cards (ie, with no KMS/DRM support)
> without xserver-xorg-legacy, right?

logind is required for drivers using KMS and *not* the legacy suid
wrapper, see /usr/share/doc/xserver-xorg-core/NEWS.Debian.gz.

I think wayland does the same (I haven't used it though).

So eventually alternatives should probably provide an alternative for
this part of logind too.

Ansgar

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Adam Borowski]

On Thu, Jan 05, 2017 at 12:19:08PM +0100, Ansgar Burchardt wrote:
> On Thu, 2017-01-05 at 11:22 +0100, Adam Borowski wrote:
> > Neither systemd-shim nor consolekit are solutions that are viable in
> > the long term, the sooner we get rid of both, the better.  I don't
> > know what's a good alternative, though.  Loginkit is
> > vapourware.  Elogind maybe?
> 
> With elogind do you mean https://github.com/wingo/elogind?  That
> project doesn't look very active.
> 
> Is there any active project trying to reimplement the logind API? 

Consolekit2 for example; it suffers from being a fork of consolekit codebase
though.

I haven't done the research, my current solution works for me so far (even
if I know it's not going to last).

> Including access to devices (which X wants these days)?

That's just for ancient graphics cards (ie, with no KMS/DRM support) without
xserver-xorg-legacy, right?


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Michael Biebl]

Am 05.01.2017 um 19:56 schrieb Michael Biebl:
> Then copy the attached wrapper script to /usr/lib/x86_64-linux-gnu/
> and make it executable.

Obviously, the wrapper script should start systemd-shim.orig.

Fixed one attached.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
#!/bin/sh

# We rely on cgmanager to setup /sys/fs/cgroup
if ! mountpoint -q /sys/fs/cgroup; then
echo "cgmanager has not setup /sys/fs/cgroup or is not running, exiting"
exit 1
fi

# Mount legacy cgroup controller at /sys/fs/cgroup/systemd
if ! mountpoint -q /sys/fs/cgroup/systemd; then
mkdir -p /sys/fs/cgroup/systemd
mount -t cgroup -o nosuid,noexec,nodev,none,name=systemd systemd 
/sys/fs/cgroup/systemd
fi

mkdir -p /run/systemd

exec /usr/lib/x86_64-linux-gnu/systemd-shim.orig


signature.asc
Description: OpenPGP digital signature

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Michael Biebl]

Am 04.01.2017 um 20:12 schrieb Ian Jackson:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things 
> [and 1 more messages]"):
>> Am 04.01.2017 um 12:07 schrieb Ian Jackson:
>>> I think #844785 needs a fix though. 
>>
>> Agreed. Does anyone who uses sysvinit want to look into this?
> 
> Um, me ?  Well, I don't particularly want to but I intend to.
> Help from all quarters gratefully accepted.

Assuming you use amd64 (adjust the paths if necessary for i386):
# mv /usr/lib/x86_64-linux-gnu/systemd-shim 
/usr/lib/x86_64-linux-gnu/systemd-shim.orig

Then copy the attached wrapper script to /usr/lib/x86_64-linux-gnu/
and make it executable.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
#!/bin/sh

# We rely on cgmanager to setup /sys/fs/cgroup
if ! mountpoint -q /sys/fs/cgroup; then
echo "cgmanager has not setup /sys/fs/cgroup not running, exiting"
exit 1
fi

# Mount legacy cgroup controller at /sys/fs/cgroup/systemd
if ! mountpoint -q /sys/fs/cgroup/systemd; then
mkdir -p /sys/fs/cgroup/systemd
mount -t cgroup -o nosuid,noexec,nodev,none,name=systemd systemd 
/sys/fs/cgroup/systemd
fi

mkdir -p /run/systemd

exec /usr/lib/x86_64-linux-gnu/systemd-shim


signature.asc
Description: OpenPGP digital signature

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ansgar Burchardt]

On Thu, 2017-01-05 at 11:22 +0100, Adam Borowski wrote:
> Neither systemd-shim nor consolekit are solutions that are viable in
> the long term, the sooner we get rid of both, the better.  I don't
> know what's a good alternative, though.  Loginkit is
> vapourware.  Elogind maybe?

With elogind do you mean https://github.com/wingo/elogind?  That
project doesn't look very active.

Is there any active project trying to reimplement the logind API? 
Including access to devices (which X wants these days)?

Ansgar

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

Adam Borowski writes ("Re: "not authorised" doing various desktoppy things [and 
1 more messages]"):
> In my experience, systemd-shim never worked in the first place, so this is
> no regression.  I see results that Ian observes since the day policykit and
> friends were recompiled against logind rather than consolekit.  It's
> somewhat puzzling that it's reported to have worked for _some_ people in the
> past.

It worked for me earlier in the year.  I don't know what set of
versions that was, but I installed one of the stretch alphas and it
worked until quite recently.  And the submitters of #844785 seem to
see something similar.

> Neither systemd-shim nor consolekit are solutions that are viable in the
> long term, the sooner we get rid of both, the better.  I don't know what's
> a good alternative, though.  Loginkit is vapourware.  Elogind maybe?

Surely this is something to think about for buster.  (Having said
that, I haven't heard of most of these things and I generally don't
have a clue what I'm doing in this area.)

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Adam Borowski]

On Wed, Jan 04, 2017 at 07:21:42PM +0100, Michael Biebl wrote:
> Am 04.01.2017 um 12:07 schrieb Ian Jackson:
> > I think #844785 needs a fix though. 
> 
> Agreed. Does anyone who uses sysvinit want to look into this?

In my experience, systemd-shim never worked in the first place, so this is
no regression.  I see results that Ian observes since the day policykit and
friends were recompiled against logind rather than consolekit.  It's
somewhat puzzling that it's reported to have worked for _some_ people in the
past.

At home, I'm still using my set of rebuilds against consolekit (semi-public
repository: http://angband.pl/debian nosystemd-{jessie,stretch})[1].  That's
not because of any love towards consolekit -- it's a piece of crap that
needs to die -- but because it works for me.

Neither systemd-shim nor consolekit are solutions that are viable in the
long term, the sooner we get rid of both, the better.  I don't know what's
a good alternative, though.  Loginkit is vapourware.  Elogind maybe?



Meow!

[1]. Also built with all references to libsystemd0 eradicated; this is not
because of bloat concerns but because in multiple cases the detection is
done at compile time rather than runtime, thus purging libsystemd0 is a
cheap way to ensure it's not needed.
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

Michael Biebl writes ("Re: "not authorised" doing various desktoppy things [and 
1 more messages]"):
> Am 04.01.2017 um 12:07 schrieb Ian Jackson:
> > I think #844785 needs a fix though. 
> 
> Agreed. Does anyone who uses sysvinit want to look into this?

Um, me ?  Well, I don't particularly want to but I intend to.
Help from all quarters gratefully accepted.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Michael Biebl]

Am 04.01.2017 um 12:07 schrieb Ian Jackson:
> I think #844785 needs a fix though. 

Agreed. Does anyone who uses sysvinit want to look into this?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Simon McVittie]

On Wed, 04 Jan 2017 at 02:10:56 +, Ian Jackson wrote:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> > Check if your session is marked as active and local
> > $ loginctl show-session $XDG_SESSION_ID
> 
> I see (amongst other things):
> 
>   Remote=no
>   Active=yes
>   State=active

Looks like the situation where polkit should allow most things.

If you were using the systemd service (and cgroup) manager, I'd ask you
to run `systemd-cgls` and/or `loginctl user-status` to visualize the
hierarchy of processes and cgroups that logind would use to match
processes to sessions, specifically looking for the process that you
think should be allowed to communicate with NetworkManager or udisks2
or other privileged services; but I don't know whether that works under
systemd-shim.

> I have frankly no idea what to expect from the
> communication between systemd-shim and systemd-logind

Mostly D-Bus, I think? Arranging for `dbus-monitor --system` to be run
as root and directed to a log before you log in might be useful. (To
work properly this requires at least stretch's version of dbus.)

> or even where to look for logs

If you were using systemd, the answer would be the Journal, or the
human-readable subset of the Journal that ends up in syslog. But you're
not, so I don't know. syslog? /proc/kmsg?

> I found this in my .xsession-errors:
> 
>  dbus-update-activation-environment: systemd --user not found, ignoring 
> --systemd argument

That should be harmless: I don't think systemd-shim is meant to start
systemd --user.

If you were using the full systemd suite, logind would have asked the
system service manager (/lib/systemd/systemd, pid 1, uid 0) to start a
user service manager (/lib/systemd/systemd --user, pid > 1, your own
uid) on your behalf, and dbus-update-activation-environment would have
communicated with the user service manager to update its idea of what
the environment should be to include whatever came from your Xsession.d.
That's a secondary function: d-u-a-e's main job is to communicate with
dbus-daemon --session to do the same thing.

polkit interactions are about system-level functionality (pid 1,
dbus-daemon --system, *dm, PAM), and not about what happens among
an individual user's processes (systemd --user, dbus-daemon --session,
.xinitrc or equivalent).

S

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

Ansgar Burchardt writes ("Re: "not authorised" doing various desktoppy things 
[and 1 more messages]"):
> Ian Jackson writes:
> > In fact I didn't have libpam-systemd installed for some strange
> > reason, but installing it hasn't helped.  (All the symptoms I report
> > above are with it installed.)
> 
> How did you not have libpam-systemd installed?  network-manager has
> Depends: policykit-1 and policykit-1 has Depends: libpam-systemd.

I'm afraid I don't know for sure.  I think this was probably a
weirdness on my system due to odd things I did to it, and not a bug in
any package dependencies.  When I asked apt-get to install
libpam-systemd, it upgraded a number of other packages.  I don't think
this is worth investigating further.

I think #844785 needs a fix though.  Tips for where to look would be
very welcome.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ansgar Burchardt]

Ian Jackson writes:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> I'm not sure I need "logind integration" in my X server but perhaps I
> do ?

Only if you want to start X as non-root.

> Simon McVittie writes ("Re: "not authorised" doing various desktoppy things"):
>> None of this works unless you have libpam-systemd installed and enabled.
>> That PAM module is somewhat mis-named: it's really for systemd-logind,
>> the user/login manager, and not the systemd init/service manager.
>
> In fact I didn't have libpam-systemd installed for some strange
> reason, but installing it hasn't helped.  (All the symptoms I report
> above are with it installed.)

How did you not have libpam-systemd installed?  network-manager has
Depends: policykit-1 and policykit-1 has Depends: libpam-systemd.

Ansgar

Re: "not authorised" doing various desktoppy things

[Nikolaus Rath]

On Jan 03 2017, Ian Jackson  wrote:
> Recently, my nm-applet can no longer control my network-manager
> daemon.  I get a message saying[1]:
>
>   "org.freedesktop.NetworkManager.network-control-request failed: not
>   authorized"
>
> I think this is related to a similar problem in *-power-manager,
> #848623.
>
> I am running:
>   * sysvinit
>   * lightdm
>   * systemd-logind
>   * vtwm
>   * my own xsession script
> I thought I was running systemd-shim but I don't appear to be.
>
> Can someone please help explain to me how these things are supposed to
> work ?

I can't explain, but just a datapoint, the following similar stack works
fine:

* systemd
* lightdm
* i3 (executed via custom .xsession)

Maybe that helps to find the crucial difference.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ian Jackson]

Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> Check if your session is marked as active and local
> $ loginctl show-session $XDG_SESSION_ID

I see (amongst other things):

  Remote=no
  Active=yes
  State=active

> Might be #844785

Perhaps it is.  The symptoms seem similar.

Obviously it's not ideal that systemd-shim is orphaned.  I would like
to fix this rather than just working around it by putting my account
in some appropriate config files.

Can anyone suggest a better strategy than a git bisect on the systemd
package source code ?  I have frankly no idea what to expect from the
communication between systemd-shim and systemd-logind, or even where
to look for logs.

I found this in my .xsession-errors:

 dbus-update-activation-environment: systemd --user not found, ignoring 
--systemd argument

And this in my Xorg.0.log:

 Xorg.0.log:[ 8.993] (II) systemd-logind: logind integration requires 
-keeptty and -keeptty was not provided, disabling logind integration

I'm not sure I need "logind integration" in my X server but perhaps I
do ?
 
Simon McVittie writes ("Re: "not authorised" doing various desktoppy things"):
> [stuff]

Thanks for the comprehensive explanation.

> None of this works unless you have libpam-systemd installed and enabled.
> That PAM module is somewhat mis-named: it's really for systemd-logind,
> the user/login manager, and not the systemd init/service manager.

In fact I didn't have libpam-systemd installed for some strange
reason, but installing it hasn't helped.  (All the symptoms I report
above are with it installed.)

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "not authorised" doing various desktoppy things

[Simon McVittie]

On Tue, 03 Jan 2017 at 21:59:05 +, Sune Vuorela wrote:
> If I recall correctly, for most
> networky (and removable media things), the default policykit
> configuration is that 'local logged in users' are allowed to do this.

They must usually be active as well as locally logged in. (This means that
if alice is on tty7, bob is on tty8, and tty7 is the visible one, then
most polkit-mediated actions will not be available to bob, which is usually
the right thing when using Ctrl+Alt+F? or many desktop environments'
"fast user switching" features.)

systemd-logind also gives active local users permission to do things with
some device nodes (specifically the ones tagged "uaccess" in udev rules)
directly, by setting POSIX ACLs on those device nodes, which are removed
when switching VT. For many device types this can't revoke access to an
already-opened device, but for some device types (input and sound, I
think?) it's possible to revoke access. You can configure that by writing
udev rules to (un)tag selected devices with "uaccess", or force the issue
by writing udev rules to set the owner or group of selected device nodes
to the one that you want to be privileged.

None of this works unless you have libpam-systemd installed and enabled.
That PAM module is somewhat mis-named: it's really for systemd-logind,
the user/login manager, and not the systemd init/service manager.

A (strong or weak) dependency relationship with libpam-systemd is
considered to be the correct way for a Debian package to declare that
it requires (or benefits from) a working systemd-logind, either via
the systemd init/service manager or systemd-shim with some other init.

> There is also somewhere iirc a configuration bit to require a password
> on the way.

Upstream defaults (along with descriptions and other metadata)
go in /usr/share/polkit-1/actions/*.policy. For example, udisks2 installs
a polkit policy file to describe the actions users can take when
asking udisks2 to manipulate storage devices on their behalf.
There are separate defaults for active local users (allow_active),
other local users (allow_inactive) and everyone else (allow_any), each
of which can be set to no, yes, auth_self, auth_admin, auth_self or
auth_admin_keep. auth_self[_keep] means require the user's own password,
auth_admin[_keep] means require the password of a root-equivalent user
(in Debian that's uid 0 or gid sudo).  These are usually set to some
reasonable compromise between "least privilege" and "things should work
automatically".

For finer-grained control or sysadmin overrides, there are configuration
files, which are the right place to put site-specific rules like "smcv may
mount and administer removable disks even if logged-in remotely". For
example, here's what my NAS box has, to get approximately the equivalent of
the old plugdev group semantics for USB disks plugged in to its front panel
(ability to run `udisksctl mount -b /dev/sde` or
`udisksctl power-off -b /dev/sde` in a ssh session):

# /etc/polkit-1/localauthority/50-local.d/usb-disks.pkla
[Allow mounting removable disks]
Identity=unix-group:plugdev

Action=org.freedesktop.udisks2.filesystem-mount-other-seat;org.freedesktop.udisks2.power-off-drive-other-seat;
ResultAny=yes

Unlike *.policy, these configuration files can match specific *identities*
(in practice Unix users and groups, although the concept is extensible).

In polkit 0.105 (jessie and stretch), upstream or Debian configuration is in
.ini-like files in /var/lib/polkit-1/localauthority/10-vendor.d/*.pkla,
and sysadmin overrides are in /etc/polkit-1/localauthority/*/*.pkla.
The syntax is like my example above.

In polkit 0.113 (upstream and experimental), upstream or Debian configuration
is JavaScript (just the language, not a full browser- or nodejs-style
runtime environment!) in /usr/share/polkit-1/rules.d/*.rules, and sysadmin
overrides for that go in /etc/polkit-1/rules.d/*.rules. My example above
would look something like this in JavaScript:

// /etc/polkit-1/rules.d/usb-disks.rules
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.udisks2.filesystem-mount-other-seat" 
||
 action.id == "org.freedesktop.udisks2.power-off-drive-other-seat") 
&&
subject.isInGroup("plugdev")) {
  return polkit.Result.YES;
}
});

> > Presumably there is also a way to override things and permanently
> > grant my account the relevant privilege.  That would be fine for
> > single-user computers (including most laptops). 
> 
> That would probably be some policykit configuration file you can do this

The polkit configuration files are the right place to do this; but on a
laptop with systemd-logind, libpam-systemd and a PAM-enabled *dm or
login prompt working together correctly, you shouldn't usually need
configuration. Those configuration files are mostly useful in two
situations:

* A user needs to grant privileges to sessions that do not involve
  

Re: "not authorised" doing various desktoppy things

[Sune Vuorela]

On 2017-01-03, Ian Jackson  wrote:
> Can someone please help explain to me how these things are supposed to
> work ?  Specifically, how is (presumably as a consequence of me
> logging in using a display manager) my session supposed to be granted
> the ability to manage various system resources like the power and
> network settings.

>
> I'd love to know where to start debugging, or where to send bug
> reports.

The rough way things work is that network-manager asks policykit if
ijackson is allowed to do . If I recall correctly, for most
networky (and removable media things), the default policykit
configuration is that 'local logged in users' are allowed to do this.
logind is asked if ijackson is logged in as a local user or as a remote
user. And the message trickles back the same way.
There is also somewhere iirc a configuration bit to require a password
on the way.

> Presumably there is also a way to override things and permanently
> grant my account the relevant privilege.  That would be fine for
> single-user computers (including most laptops). 

That would probably be some policykit configuration file you can do this

> But I want to fix
> this in the general case.  I suspect that (for example) desktoppy
> removeable media, or audio access, may be affected (although I don't
> use those things).

I like your attitude of fixing the general case, and I do have the same
suspicion as you.

I do think mbiebl's debugging start point is good.

/Sune

Re: "not authorised" doing various desktoppy things

[Michael Biebl]

Am 03.01.2017 um 21:05 schrieb Ian Jackson:
> Recently, my nm-applet can no longer control my network-manager
> daemon.  I get a message saying[1]:
> 
>   "org.freedesktop.NetworkManager.network-control-request failed: not
>   authorized"
> 
> I think this is related to a similar problem in *-power-manager,
> #848623.
> 
> I am running:
>   * sysvinit

>   * systemd-logind

Check if your session is marked as active and local

$ loginctl show-session $XDG_SESSION_ID

Might be #844785
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

"not authorised" doing various desktoppy things

[Ian Jackson]

Recently, my nm-applet can no longer control my network-manager
daemon.  I get a message saying[1]:

  "org.freedesktop.NetworkManager.network-control-request failed: not
  authorized"

I think this is related to a similar problem in *-power-manager,
#848623.

I am running:
  * sysvinit
  * lightdm
  * systemd-logind
  * vtwm
  * my own xsession script
I thought I was running systemd-shim but I don't appear to be.

Can someone please help explain to me how these things are supposed to
work ?  Specifically, how is (presumably as a consequence of me
logging in using a display manager) my session supposed to be granted
the ability to manage various system resources like the power and
network settings.

I'd love to know where to start debugging, or where to send bug
reports.

Presumably there is also a way to override things and permanently
grant my account the relevant privilege.  That would be fine for
single-user computers (including most laptops).  But I want to fix
this in the general case.  I suspect that (for example) desktoppy
removeable media, or audio access, may be affected (although I don't
use those things).

Ian.

[1] copy typed because I can't c - wtf, is this windows ?

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.