Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 01:12:12AM +0100, Ken Moffat via blfs-dev wrote:
> On Sat, Aug 24, 2019 at 05:57:10PM -0500, Bruce Dubbs via blfs-dev wrote:
> > On 8/24/19 4:38 PM, Ken Moffat via blfs-dev wrote:
> >
> > polkit.addAdminRule(function(action, subject) {
> > return ["unix-group:wheel"];
> > });
> >
> > On my system, I am a member of the wheel group, but I didn't add that
> > recently. It is legacy. Are you a member of the wheel group?
>
> No. I don't really want to be (if ken is running something that
> needs root access, he ought to have to 'su' to remind him of the
> dangers ;) But I do remember there was _something_ about being a
> member of the wheel group in the past few months, although I don't
> remember the details.
>
We've since established that being in the wheel group is not
necessary for rootless X, but I'm coming back to add an explanation
of the above rule which I found in the Arch wiki during my continual
"stumbling around in the dark in google results" :
That rule says users in the wheel group *can* authenticate, But to
do that they need to input a password, either via a desktop agent
such as lxpolkit, polkit-gnome, xfce-polkit or else using the tty
fallback of pkttyagent from polkit itself.
ĸen
--
Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir.
I can do the rite of k'zakra, I know the secrets of h'ragna, I can
ha'lk my g'rakha correctly ... I am a dwarf
Captain Carrot Ironfoundersson (in The Fifth Elephant)
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Mon, Aug 26, 2019 at 05:41:15PM +0200, Armin K. via blfs-dev wrote:
>
> You seem to be missing one important piece of software in this
> discussion, and that's the one and only device manager, the (E)Udev.
> (E)Udev is responsible for "tagging" a device that can be accessed
> through a seat that is managed by (E)logind.
>
> What I'd suggest for you Ken, is to verify the existence of the
> following (E)Udev rules on your system:
>
> https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4
>
the only match for 'input' is
# joysticks
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="uaccess"
But according to
https://unix.stackexchange.com/questions/467382/udev-uaccess-and-hid
Access is granted and revoked to open file descriptors, instead of
the device node.
And there is a link to
https://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/
> https://github.com/systemd/systemd/blob/master/src/login/71-seat.rules.in
>
This looks more hopeful
SUBSYSTEM=="input", KERNEL=="input*", TAG+="seat"
I guess that should be what controls this.
> https://github.com/systemd/systemd/blob/master/src/login/73-seat-late.rules.m4
>
And that rules file exists.
> Your (E)udev needs to be built with ACL support, as the access to the
> tagged nodes is granted through access controls. You can verify if your
> user has correct access on the nodes with "getfacl /dev/input/event0"
> for example.
>
> This way, no old-fashined group membership is required for audio, video,
> cdrom, input, etc groups - if you have a local seat you have access to
> these nodes, and they are granted using access controls by udev itself.
>
On my systems with elogind, nothing -
getfacl: Removing leading '/' from absolute path names
# file: dev/input/event0
# owner: root
# group: input
user::rw-
group::rw-
other::---
And after the noise when changing to a different tty I did set the
following in my kernels:
CONFIG_TMPFS_POSIX_ACL=y
which also enabled
CONFIG_TMPFS_XATTR=y
The log from my build of eudev has no mention of acl or ACL.
> Kind regards.
Thanks. I'm convinced there is probably something simple and
trivial missing. Will look at the google results for
elogind seat access not working
Hmm, the many pages turned out to be far fewer as I dug down.
https://github.com/elogind/elogind/issues/61
Running X on tty1 with myself in the input group ind switching to
tty2 to run loginctl shows
SESSION UID USER SEAT TTY
c1 1000 ken seat0 tty1
c2 1000 ken seat0 tty2
2 sessions listed.
Hmm, following on from that I looked at the linked
/etc/pam.d/system-auth:
# This file is part of elogind.
auth sufficient pam_unix.so nullok try_first_pass
account required pam_nologin.so
account sufficient pam_unix.so
password sufficient pam_unix.so nullok sha512 shadow try_first_pass try_authtok
-session optional pam_loginuid.so
-session optional pam_elogind.so
session sufficient pam_unix.so
I'm not quite sure why the two optional lines there start with '-'
(it's a file, not a diff).
My own is (hopefully) the same as in BLFS ?, without any mention of
pam_elogind.so which is instead in /etc/pam.d/elogind-user
# Begin /etc/pam.d/system-auth
auth requiredpam_unix.so
# End /etc/pam.d/system-auth
and
# Begin /etc/pam.d/elogind-user
account requiredpam_access.so
account include system-account
session requiredpam_env.so
session requiredpam_limits.so
session requiredpam_unix.so
session requiredpam_loginuid.so
session optionalpam_keyinit.so force revoke
session optionalpam_elogind.so
auth requiredpam_deny.so
password requiredpam_deny.so
# End /etc/pam.d/elogind-user
ĸen
--
Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir.
I can do the rite of k'zakra, I know the secrets of h'ragna, I can
ha'lk my g'rakha correctly ... I am a dwarf
Captain Carrot Ironfoundersson (in The Fifth Elephant)
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
Armin K. via blfs-dev wrote: On 25. 8. 2019. 19:38, Bruce Dubbs via blfs-dev wrote: On 8/25/19 12:18 PM, Pierre Labastie via blfs-dev wrote: [snip] /dev/input/xxx. Actually, I don't think polkit is involved for accessing those: it is the whole purpose of dbus to provide access to hardware devices for normal users. That's my biggest problem wit dbus. According the the website: "D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed." But why do they need to combine interprocess communication with "launch applications and daemons"? IMO, this is the systemd disease. It just makes things more complicated. -- Bruce Hi, You seem to be missing one important piece of software in this discussion, and that's the one and only device manager, the (E)Udev. (E)Udev is responsible for "tagging" a device that can be accessed through a seat that is managed by (E)logind. What I'd suggest for you Ken, is to verify the existence of the following (E)Udev rules on your system: https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4 https://github.com/systemd/systemd/blob/master/src/login/71-seat.rules.in https://github.com/systemd/systemd/blob/master/src/login/73-seat-late.rules.m4 Those files are installed by elogind (with slight modifications, I think), in /lib/udev/rules.d. Your (E)udev needs to be built with ACL support, as the access to the tagged nodes is granted through access controls. You can verify if your user has correct access on the nodes with "getfacl /dev/input/event0" for example. Actually, for me, I am presently running X with functional mouse and keyboard, I am not in the wheel group, and getfacl /dev/input/event0 returns: --- getfacl: Removing leading '/' from absolute path names # file: dev/input/event0 # owner: root # group: input user::rw- group::rw- other::--- -- That is, no ACL... That's a difference with: - $getfacl /dev/dri/card0 getfacl: Removing leading '/' from absolute path names # file: dev/dri/card0 # owner: root # group: video user::rw- user:pierre:rw- group::rw- mask::rw- other::--- - This way, no old-fashined group membership is required for audio, video, cdrom, input, etc groups - if you have a local seat you have access to these nodes, and they are granted using access controls by udev itself. Kind regards. Not sure about the exact mechanism, but I agree with the fact that those memberships are not needed anymore. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/26/19 10:41 AM, Armin K. via blfs-dev wrote: On 25. 8. 2019. 19:38, Bruce Dubbs via blfs-dev wrote: On 8/25/19 12:18 PM, Pierre Labastie via blfs-dev wrote: [snip] /dev/input/xxx. Actually, I don't think polkit is involved for accessing those: it is the whole purpose of dbus to provide access to hardware devices for normal users. That's my biggest problem wit dbus. According the the website: "D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed." But why do they need to combine interprocess communication with "launch applications and daemons"? IMO, this is the systemd disease. It just makes things more complicated. -- Bruce Hi, You seem to be missing one important piece of software in this discussion, and that's the one and only device manager, the (E)Udev. (E)Udev is responsible for "tagging" a device that can be accessed through a seat that is managed by (E)logind. What I'd suggest for you Ken, is to verify the existence of the following (E)Udev rules on your system: https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4 https://github.com/systemd/systemd/blob/master/src/login/71-seat.rules.in https://github.com/systemd/systemd/blob/master/src/login/73-seat-late.rules.m4 Your (E)udev needs to be built with ACL support, as the access to the tagged nodes is granted through access controls. You can verify if your user has correct access on the nodes with "getfacl /dev/input/event0" for example. This way, no old-fashined group membership is required for audio, video, cdrom, input, etc groups - if you have a local seat you have access to these nodes, and they are granted using access controls by udev itself. Hi Armin. Long time eudev and acl are built in LFS. http://www.linuxfromscratch.org/lfs/view/development/chapter06/eudev.html -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 25. 8. 2019. 19:38, Bruce Dubbs via blfs-dev wrote: On 8/25/19 12:18 PM, Pierre Labastie via blfs-dev wrote: [snip] /dev/input/xxx. Actually, I don't think polkit is involved for accessing those: it is the whole purpose of dbus to provide access to hardware devices for normal users. That's my biggest problem wit dbus. According the the website: "D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed." But why do they need to combine interprocess communication with "launch applications and daemons"? IMO, this is the systemd disease. It just makes things more complicated. -- Bruce Hi, You seem to be missing one important piece of software in this discussion, and that's the one and only device manager, the (E)Udev. (E)Udev is responsible for "tagging" a device that can be accessed through a seat that is managed by (E)logind. What I'd suggest for you Ken, is to verify the existence of the following (E)Udev rules on your system: https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4 https://github.com/systemd/systemd/blob/master/src/login/71-seat.rules.in https://github.com/systemd/systemd/blob/master/src/login/73-seat-late.rules.m4 Your (E)udev needs to be built with ACL support, as the access to the tagged nodes is granted through access controls. You can verify if your user has correct access on the nodes with "getfacl /dev/input/event0" for example. This way, no old-fashined group membership is required for audio, video, cdrom, input, etc groups - if you have a local seat you have access to these nodes, and they are granted using access controls by udev itself. Kind regards. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 08:27:03PM +0100, Ken Moffat via blfs-dev wrote: > > First, can I mention that I overthought my attitude to adding my > user to the wheel group ? This is a developer's workstation (for > some value of workstation) with a single human user. Being in the > wheel group doesn't of itself let me do things using my own password > in sudo, so objecting to that is excessive. > > Therefore, I've added myself to the wheel group in the current > build. > Did not work, elogind definitely starts and daemon.log showed: Aug 26 00:05:16 plexi dbus-daemon[1145]: [system] Activating service name='org.freedesktop.login1' requested by ':1.0' (uid=0 pid=1311 comm="/bin/login -- ") (using servicehelper) Aug 26 00:05:16 plexi dbus-daemon[1145]: [system] Successfully activated service 'org.freedesktop.login1' But despite that 'successfully' I still got the permission problem. So then I tried adding a brand new user (new-boy, in group new-group) with a really cut-down .xinitrc to just start fluxbox : similar result, i.e. desktop appeared but no keyboard or mouse. After rebooting, new-boy's Xorg log shows the same 'Permission denied' on each of the /dev/input/event files. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 07:18:33PM +0200, Pierre Labastie via blfs-dev wrote: > On 25/08/2019 18:26, Ken Moffat via blfs-dev wrote: > > > > On the pre-9.0 system on my haswell I'll explore membership of the > > wheel group. Failed to startx, I think I've broken something there. But that was supposed to be a "generic" build (the sort I should be able to copy to a new machine, fix up the kernel, and use to boot a new LFS) and I'd accidentally left -march=native in the glibc build. So, I'm doing a fresh build of that system, with myself in the wheel group. > > I've added myself to the wheel group to see if it could change something for > the gdm problem. > But before that, I've been able to start X without belonging to this group > several times before (and during my first adventures with gdm too). So no, I > do not think you need to belong to an administrative group to access > /dev/input/xxx. Actually, I don't think polkit is involved for accessing > those: it is the whole purpose of dbus to provide access to hardware devices > for normal users. > The devices in this case being /dev/input/* > I've not read the whole thread in details (have been out of town for a day and > a half), so you may already have tried this, but I would suggest that you try > to recompile elogind, Xorg libraries, and then dbus again. > What are you suggesting I should do differently in recompiling elogind ? I've already compiled dbus for a first time, elogind, xtrans and the rest of the xorg libs, dbus again, the usual stuff including pixman, libdrm, Mesa, some xorg apps, polkit with its deps, and then xorg-server. I appreciate you haven't read the whole set of threads/subthreads, so may I post soemthing I wrote earlier (reformatted) ? From /usr/share/polkit-1/actions/org.freedesktop.login1.policy Allow attaching devices to seats Authentication is required for attaching a device to a seat. auth_admin_keep auth_admin_keep auth_admin_keep org.freedesktop.login1.flush-devices Please note that this authentication is auth_admin_keep. From https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html auth_admin Authentication by an administrative user is required. [...] auth_admin_keep Like auth_admin but the authorization is kept for a brief period (e.g. five minutes). That is why I think being an administrative user is required. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 06:39:03PM +0100, hazel debian via blfs-dev wrote: > My understanding of polkit is that it isn't concerned with hardware access > at all but with access to certain actions within programs. Polkit-aware > programs list their available actions and these are rationed out to > different kinds of users, both active and inactive. > You have a much better, and more concise, understanding of it than I do. But in this case, my reading of the action (see the reply to Pierre I've just sent) is that "Allow attaching devices to seats" is what allows users logged-in locally and not in the input group to use /dev/input/event* (and whatever modem devices are used by ModemManager). ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/25/2019 7:41 AM, Pierre Labastie via blfs-dev wrote: On 25/08/2019 04:56, DJ Lucas via blfs-dev wrote: On 8/24/2019 9:53 PM, Ken Moffat via blfs-dev wrote: Not sure how any of this fits with Pierre's earlier observation about multiple users on the same machine, and frankly that part is not my problem. Now I really WILL step away from the machine. Goodnight, thanks for the assistance. Goodnight. Thanks for the assistance. I think ultimately we go back to setuid Xorg for now. We'll see what happens from there. Well, I won't oppose that, although I do not like it: on this system, apart from the keyboard issue with gdm, I have all DE's working (not tested thoroughly, though), with a non suid Xorg and mountcgroupfs disabled. For the permissions: as soon a logind is started it adds some ACL's to /dev/dri/card0 for the logged in user (even if logged in on the console, I think): for example: $ getfacl /dev/dri/card0 # file: dev/dri/card0 # owner: root # group: video user::rw- user:pierre:rw- group::rw- mask::rw- other::--- So no need to belong to the video group. Note that the ACL is not changed if you do 'su - new-user'. OTOH, for the /dev/input/* files, their permissions do not seem to be changed. But I can tell you that I have functional keyboard and mouse, without belonging to the input group. Yes, the input devices get associated with the seat. I'm in the same boat. It has and does work perfectly for a regular user with only primary group membership. I am unable to figure out why the polkit mechanism is not working for some. My point is that we've always had Xorg suid in the SysV book. While I am reluctant to do so, we haven't been successful in finding whatever it is that I've missed in elogind's introduction to the book, and I just don't think this issue should put any more strain on the release, as it is not a regression. There is a less desirable method for handling suid bit for the Xorg bin. We could add a note with instructions for the suid bit in the event that there is a problem on your particular build. For the book, I lean towards just putting back the suid bit as it was, as I place a higher value on the consistency between different builds, but that is strictly my opinion. While I don't particularly like either suggestion, I suppose all are worth consideration. OTOH, dropping the elogind and mountcgroupfs bootscripts absolutely should happen before release. The PAM configuration works just fine in both user sessions and DM sessions (regardless of the seat association); the scripts just add needless complexity. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/25/19 12:18 PM, Pierre Labastie via blfs-dev wrote: [snip] /dev/input/xxx. Actually, I don't think polkit is involved for accessing those: it is the whole purpose of dbus to provide access to hardware devices for normal users. That's my biggest problem wit dbus. According the the website: "D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed." But why do they need to combine interprocess communication with "launch applications and daemons"? IMO, this is the systemd disease. It just makes things more complicated. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 6:21 PM Pierre Labastie via blfs-dev < blfs-dev@lists.linuxfromscratch.org> wrote: > On 25/08/2019 18:26, Ken Moffat via blfs-dev wrote: > > On Sun, Aug 25, 2019 at 02:41:17PM +0200, Pierre Labastie via blfs-dev > wrote: > >> On 25/08/2019 04:56, DJ Lucas via blfs-dev wrote: > >>> > >>> > >>> On 8/24/2019 9:53 PM, Ken Moffat via blfs-dev wrote: > Not sure how any of this fits with Pierre's earlier observation > about multiple users on the same machine, and frankly that part is > not my problem. Now I really WILL step away from the machine. > > Goodnight, thanks for the assistance. > >>> Goodnight. Thanks for the assistance. I think ultimately we go back to > setuid > >>> Xorg for now. We'll see what happens from there. > >>> > >> > >> Well, I won't oppose that, although I do not like it: on this system, > apart > >> from the keyboard issue with gdm, I have all DE's working (not tested > >> thoroughly, though), with a non suid Xorg and mountcgroupfs disabled. > >> > > > > Hi Pierre, > > > > I agree that going back to setuid seems unnecessary. > > > > Are you in the wheel group ? > > > >> For the permissions: as soon a logind is started it adds some ACL's to > >> /dev/dri/card0 for the logged in user (even if logged in on the > console, I > >> think): for example: > >> > >> $ getfacl /dev/dri/card0 > >> # file: dev/dri/card0 > >> # owner: root > >> # group: video > >> user::rw- > >> user:pierre:rw- > >> group::rw- > >> mask::rw- > >> other::--- > >> > >> So no need to belong to the video group. > >> > > > > At the moment I'm on the old machine, where I was intending to get > > the mouse working - but I think I've got hardware failures (on > > recent systems, Xorg comes up with a resolution which the monitor > > doesn't support and the log shows modelines only for 1024x768 and > > lower). > > > > On the pre-9.0 system on my haswell I'll explore membership of the > > wheel group. > > > >> Note that the ACL is not changed if you do 'su - new-user'. > >> > >> OTOH, for the /dev/input/* files, their permissions do not seem to be > changed. > >> But I can tell you that I have functional keyboard and mouse, without > >> belonging to the input group. > >> > >> Pierre > > > > My _current_ understanding is that with the whole elogind stack, > > polkit provides the authorization for /dev/input/ but only for admin > > users, and an admin user appears to mean anybody in the wheel group. > > > > I've added myself to the wheel group to see if it could change something > for > the gdm problem. > But before that, I've been able to start X without belonging to this group > several times before (and during my first adventures with gdm too). So no, > I > do not think you need to belong to an administrative group to access > /dev/input/xxx. Actually, I don't think polkit is involved for accessing > those: it is the whole purpose of dbus to provide access to hardware > devices > for normal users. > My understanding of polkit is that it isn't concerned with hardware access at all but with access to certain actions within programs. Polkit-aware programs list their available actions and these are rationed out to different kinds of users, both active and inactive. > > I've not read the whole thread in details (have been out of town for a day > and > a half), so you may already have tried this, but I would suggest that you > try > to recompile elogind, Xorg libraries, and then dbus again. > > Pierre > -- > http://lists.linuxfromscratch.org/listinfo/blfs-dev > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/25/2019 11:26 AM, Ken Moffat via blfs-dev wrote: My _current_ understanding is that with the whole elogind stack, polkit provides the authorization for /dev/input/ but only for admin users, and an admin user appears to mean anybody in the wheel group. To expand on Pierre's answer a bit, ultimately, the needed input devices get tied to the user's "seat" and that is how an unprivileged user can access the device. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 25/08/2019 18:26, Ken Moffat via blfs-dev wrote: > On Sun, Aug 25, 2019 at 02:41:17PM +0200, Pierre Labastie via blfs-dev wrote: >> On 25/08/2019 04:56, DJ Lucas via blfs-dev wrote: >>> >>> >>> On 8/24/2019 9:53 PM, Ken Moffat via blfs-dev wrote: Not sure how any of this fits with Pierre's earlier observation about multiple users on the same machine, and frankly that part is not my problem. Now I really WILL step away from the machine. Goodnight, thanks for the assistance. >>> Goodnight. Thanks for the assistance. I think ultimately we go back to >>> setuid >>> Xorg for now. We'll see what happens from there. >>> >> >> Well, I won't oppose that, although I do not like it: on this system, apart >> from the keyboard issue with gdm, I have all DE's working (not tested >> thoroughly, though), with a non suid Xorg and mountcgroupfs disabled. >> > > Hi Pierre, > > I agree that going back to setuid seems unnecessary. > > Are you in the wheel group ? > >> For the permissions: as soon a logind is started it adds some ACL's to >> /dev/dri/card0 for the logged in user (even if logged in on the console, I >> think): for example: >> >> $ getfacl /dev/dri/card0 >> # file: dev/dri/card0 >> # owner: root >> # group: video >> user::rw- >> user:pierre:rw- >> group::rw- >> mask::rw- >> other::--- >> >> So no need to belong to the video group. >> > > At the moment I'm on the old machine, where I was intending to get > the mouse working - but I think I've got hardware failures (on > recent systems, Xorg comes up with a resolution which the monitor > doesn't support and the log shows modelines only for 1024x768 and > lower). > > On the pre-9.0 system on my haswell I'll explore membership of the > wheel group. > >> Note that the ACL is not changed if you do 'su - new-user'. >> >> OTOH, for the /dev/input/* files, their permissions do not seem to be >> changed. >> But I can tell you that I have functional keyboard and mouse, without >> belonging to the input group. >> >> Pierre > > My _current_ understanding is that with the whole elogind stack, > polkit provides the authorization for /dev/input/ but only for admin > users, and an admin user appears to mean anybody in the wheel group. > I've added myself to the wheel group to see if it could change something for the gdm problem. But before that, I've been able to start X without belonging to this group several times before (and during my first adventures with gdm too). So no, I do not think you need to belong to an administrative group to access /dev/input/xxx. Actually, I don't think polkit is involved for accessing those: it is the whole purpose of dbus to provide access to hardware devices for normal users. I've not read the whole thread in details (have been out of town for a day and a half), so you may already have tried this, but I would suggest that you try to recompile elogind, Xorg libraries, and then dbus again. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 02:41:17PM +0200, Pierre Labastie via blfs-dev wrote: > On 25/08/2019 04:56, DJ Lucas via blfs-dev wrote: > > > > > > On 8/24/2019 9:53 PM, Ken Moffat via blfs-dev wrote: > >> Not sure how any of this fits with Pierre's earlier observation > >> about multiple users on the same machine, and frankly that part is > >> not my problem. Now I really WILL step away from the machine. > >> > >> Goodnight, thanks for the assistance. > > Goodnight. Thanks for the assistance. I think ultimately we go back to > > setuid > > Xorg for now. We'll see what happens from there. > > > > Well, I won't oppose that, although I do not like it: on this system, apart > from the keyboard issue with gdm, I have all DE's working (not tested > thoroughly, though), with a non suid Xorg and mountcgroupfs disabled. > Hi Pierre, I agree that going back to setuid seems unnecessary. Are you in the wheel group ? > For the permissions: as soon a logind is started it adds some ACL's to > /dev/dri/card0 for the logged in user (even if logged in on the console, I > think): for example: > > $ getfacl /dev/dri/card0 > # file: dev/dri/card0 > # owner: root > # group: video > user::rw- > user:pierre:rw- > group::rw- > mask::rw- > other::--- > > So no need to belong to the video group. > At the moment I'm on the old machine, where I was intending to get the mouse working - but I think I've got hardware failures (on recent systems, Xorg comes up with a resolution which the monitor doesn't support and the log shows modelines only for 1024x768 and lower). On the pre-9.0 system on my haswell I'll explore membership of the wheel group. > Note that the ACL is not changed if you do 'su - new-user'. > > OTOH, for the /dev/input/* files, their permissions do not seem to be changed. > But I can tell you that I have functional keyboard and mouse, without > belonging to the input group. > > Pierre My _current_ understanding is that with the whole elogind stack, polkit provides the authorization for /dev/input/ but only for admin users, and an admin user appears to mean anybody in the wheel group. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 25/08/2019 04:56, DJ Lucas via blfs-dev wrote: > > > On 8/24/2019 9:53 PM, Ken Moffat via blfs-dev wrote: >> Not sure how any of this fits with Pierre's earlier observation >> about multiple users on the same machine, and frankly that part is >> not my problem. Now I really WILL step away from the machine. >> >> Goodnight, thanks for the assistance. > Goodnight. Thanks for the assistance. I think ultimately we go back to setuid > Xorg for now. We'll see what happens from there. > Well, I won't oppose that, although I do not like it: on this system, apart from the keyboard issue with gdm, I have all DE's working (not tested thoroughly, though), with a non suid Xorg and mountcgroupfs disabled. For the permissions: as soon a logind is started it adds some ACL's to /dev/dri/card0 for the logged in user (even if logged in on the console, I think): for example: $ getfacl /dev/dri/card0 # file: dev/dri/card0 # owner: root # group: video user::rw- user:pierre:rw- group::rw- mask::rw- other::--- So no need to belong to the video group. Note that the ACL is not changed if you do 'su - new-user'. OTOH, for the /dev/input/* files, their permissions do not seem to be changed. But I can tell you that I have functional keyboard and mouse, without belonging to the input group. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/2019 9:53 PM, Ken Moffat via blfs-dev wrote: Not sure how any of this fits with Pierre's earlier observation about multiple users on the same machine, and frankly that part is not my problem. Now I really WILL step away from the machine. Goodnight, thanks for the assistance. Goodnight. Thanks for the assistance. I think ultimately we go back to setuid Xorg for now. We'll see what happens from there. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sat, Aug 24, 2019 at 09:00:36PM -0500, Bruce Dubbs via blfs-dev wrote: > On 8/24/19 8:14 PM, Ken Moffat via blfs-dev wrote: > > It's installed right at the end of my log after installing the header files. > > -- Bruce Yeah, I managed to boot a system from a couple of weeks ago, which had elogind but where I'd accidentally installed Xorg suid and thought all was working. I was going to step away from the machine, but I thought I'd look up about admin users on rootless X, and I came across: https://wiki.gentoo.org/wiki/Non_root_Xorg which notes: As of Nov. 6, 2018, the information in this section is probably outdated. You can help the Gentoo community by verifying and updating this section But then goes on to say: Now you can run X as user, however because none of login managers are currently capable of doing necessary permission handling it needs some workarounds. In particular, X run by user needs to be able to access /dev/input files and it needs to be started directly as the user. Additionally, as with using direct rendering, the unprivileged user also needs access to the video hardware, typically achieved by adding them to the video group (though certain login managers, such as ConsoleKit or systemd-logind may handle this for you). To access /dev/input files it's easiest to add them to group and allow user to access them. [end quote] I'll note that all the input event and mice|mouse chardevs are currently owned by root:input. So, I guess this gives two options for using rootles X: 1. Be an admin user, i.e. in the wheel group. 2. Be a member of the input group. In the (for me, unlikely) situations of either logging in to a desktop via ssh (when I've left a desktop running), or having TWO human users with individually assigned graphics cards, might give problems in either event. But for me, I'm starting to think that membership of the input group might be the better approach. And I still think that a minimum of one machine per desktop user (with integrated graphics if low-power is a requirement) is a better approach than trying to squeeze multiple people onto one big machine (after all, how many modern graphics cards can you actually fit into one machine ?). But for people who want to have multiple desktop users per machine, there are guides (or variants of hte same guide) at e.g. Arch, debian. Not sure how any of this fits with Pierre's earlier observation about multiple users on the same machine, and frankly that part is not my problem. Now I really WILL step away from the machine. Goodnight, thanks for the assistance. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 01:33:12AM +, DJ Lucas via blfs-dev wrote: > > > On 8/24/2019 8:14 PM, Ken Moffat via blfs-dev wrote: > > On Sun, Aug 25, 2019 at 12:42:12AM +, DJ Lucas via blfs-dev wrote: > > > > At this point, I'm clearly out of my depth, and I will not be > > > > updating further systems (nor reviewing if the kernel config for > > > > elogind is adequate, nor if the mountcgroupfs and elogind > > > > bootscripts are really needed) unless I can understand where my > > > > build/usage of elogind is failing. > > > > > > > > ĸen > > > The seat actions are at > > > /usr/share/polkit-1/actions/org.freedesktop.login1.policy > > > > > > --DJ > > > > > Thanks, but not on this system :-( > > > > ken@plexi ~ $ls /usr/share/polkit-1/actions/ > > com.mesonbuild.install.policy > > org.freedesktop.policykit.policy > > org.freedesktop.color.policy > > org.gtk.vfs.file-operations.policy > > org.freedesktop.policykit.examples.pkexec.policy > > org.x.xf86-video-intel.backlight-helper.policy > > > > ĸen > But I do think we might be getting someplace. Did you log your elogind > build? If so, what was the meson summary output? Here is what I had: > > Message: elogind 241.3 > split /usr:true > split bin-sbin:true > prefix directory: /usr > rootprefix directory: / > sysconf directory: /etc > include directory: /usr/include > lib directory: /usr/lib > rootlib directory: /lib > rootexeclib dir: /lib/elogind > PAM modules directory: /lib/security > PAM configuration directory: /etc/pam.d > modprobe.d directory: /lib/modprobe.d > D-Bus policy directory:/etc/dbus-1/system.d > D-Bus session directory: /usr/share/dbus-1/services > D-Bus system directory:/usr/share/dbus-1/system-services > bash completions directory: > /usr/share/bash-completion/completions > zsh completions directory: /usr/share/zsh/site-functions > TTY GID: 5 > maximum system UID:999 > maximum system GID:999 > /dev/kvm access mode: 0666 > render group access mode: 0666 > nobody user name: nobody > nobody group name: nobody > default KillUserProcesses setting: true > enabled features: PAM, SMACK, ACL, polkit, dbus, man pages, utmp > disabled features: AUDIT, SELinux, legacy pkla, glib, html pages, > man page indices, debug elogind, debug hashmap, debug mmap cache, debug > siphash, valgrind, trace logging > It agrees on all of those. References to login1 are Installing /scratch/working/elogind-241.3/src/login/org.freedesktop.login1.conf to /etc/dbus-1/system.d Installing /scratch/working/elogind-241.3/build/src/login/org.freedesktop.login1.service to /usr/share/dbus-1/system-services Installing /scratch/working/elogind-241.3/src/login/org.freedesktop.login1.policy to /usr/share/polkit-1/actions Oh, spit - I think I must have accidentally booted the system next to it in grub's menu when I was taking it up and down. I'm now definitely on 9.0: ken@plexi ~ $cat /etc/lfs-release LFS-9.0 (r11659, -rc1). BLFS r21977 DISTRIB_RELEASE="LFS-9.0" DISTRIB_CODENAME="Llamedos" DISTRIB_DESCRIPTION="Linux From Scratch" and I _do_ have that file. Sorry for the noise. I suppose the relevant part is: Allow attaching devices to seats Authentication is required for attaching a device to a seat. auth_admin_keep auth_admin_keep auth_admin_keep org.freedesktop.login1.flush-devices From https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html auth_admin Authentication by an administrative user is required. [...] auth_admin_keep Like auth_admin but the authorization is kept for a brief period (e.g. five minutes). Which I think means that a user who wants to use Xorg does need to be in the wheel group? I can't say that I like that, but since my groups seem to have become totally banjaxed (and I've still no idea where that '7' came from) I'm going to step away from the machines. Thanks for your help, and sorry for the wrong answer earlier. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) --
Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 02:46:19AM +0100, Ken Moffat via blfs-dev wrote: > On Sat, Aug 24, 2019 at 08:05:41PM -0500, Bruce Dubbs via blfs-dev wrote: > > > > As best I can tell, our configurations are the same. I do have both the > > elogind and mountcgroupfs bootscripts running at startup. The only thing > > left that I can tell is that we may have used different build procedures. > > Have you modified anything from the book's instructions? AFAIK I used the > > exact instructions in the book. No flags or other changes. > > > > Thanks. For the moment, both the mountcgroupfs and elogind > bootscripts have been started. > > I've been trying to add myself to the wheel group, but not > necessarily successfully: > > ken@plexi ~$ groups > users lp audio video cdrom lpadmin netdev > ken@plexi ~$ grep 'wheel' /etc/group* > /etc/group:wheel:x:97:7:ken > /etc/group-:wheel:x:97:ken > ken@plexi ~$ > > Those are after rebooting following 'usermod'. > Postscript: I can see I've typo'd that when trying to edit /etc/group after apparently not being in it from usermod. The '7' gets added between the start of LFS chapter 6 and the end of the packages I build before rebooting - just found it on another machine where I was going to see if I could get different results. Oh, and in 9.0 the mouse on that machine is not working (linux-5.2.8) although it seems to work on other systems there . -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/19 8:14 PM, Ken Moffat via blfs-dev wrote: On Sun, Aug 25, 2019 at 12:42:12AM +, DJ Lucas via blfs-dev wrote: At this point, I'm clearly out of my depth, and I will not be updating further systems (nor reviewing if the kernel config for elogind is adequate, nor if the mountcgroupfs and elogind bootscripts are really needed) unless I can understand where my build/usage of elogind is failing. ĸen The seat actions are at /usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ Thanks, but not on this system :-( ken@plexi ~ $ls /usr/share/polkit-1/actions/ com.mesonbuild.install.policy org.freedesktop.policykit.policy org.freedesktop.color.policy org.gtk.vfs.file-operations.policy org.freedesktop.policykit.examples.pkexec.policy org.x.xf86-video-intel.backlight-helper.policy In my build log for elongind I have: Installing /build/elogind/elogind-241.3/src/login/org.freedesktop.login1.policy to /usr/share/polkit-1/actions It's installed right at the end of my log after installing the header files. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/2019 8:14 PM, Ken Moffat via blfs-dev wrote: On Sun, Aug 25, 2019 at 12:42:12AM +, DJ Lucas via blfs-dev wrote: At this point, I'm clearly out of my depth, and I will not be updating further systems (nor reviewing if the kernel config for elogind is adequate, nor if the mountcgroupfs and elogind bootscripts are really needed) unless I can understand where my build/usage of elogind is failing. ĸen The seat actions are at /usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ Thanks, but not on this system :-( ken@plexi ~ $ls /usr/share/polkit-1/actions/ com.mesonbuild.install.policy org.freedesktop.policykit.policy org.freedesktop.color.policy org.gtk.vfs.file-operations.policy org.freedesktop.policykit.examples.pkexec.policy org.x.xf86-video-intel.backlight-helper.policy ĸen But I do think we might be getting someplace. Did you log your elogind build? If so, what was the meson summary output? Here is what I had: Message: elogind 241.3 split /usr:true split bin-sbin:true prefix directory: /usr rootprefix directory: / sysconf directory: /etc include directory: /usr/include lib directory: /usr/lib rootlib directory: /lib rootexeclib dir: /lib/elogind PAM modules directory: /lib/security PAM configuration directory: /etc/pam.d modprobe.d directory: /lib/modprobe.d D-Bus policy directory:/etc/dbus-1/system.d D-Bus session directory: /usr/share/dbus-1/services D-Bus system directory:/usr/share/dbus-1/system-services bash completions directory: /usr/share/bash-completion/completions zsh completions directory: /usr/share/zsh/site-functions TTY GID: 5 maximum system UID:999 maximum system GID:999 /dev/kvm access mode: 0666 render group access mode: 0666 nobody user name: nobody nobody group name: nobody default KillUserProcesses setting: true enabled features: PAM, SMACK, ACL, polkit, dbus, man pages, utmp disabled features: AUDIT, SELinux, legacy pkla, glib, html pages, man page indices, debug elogind, debug hashmap, debug mmap cache, debug siphash, valgrind, trace logging -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sat, Aug 24, 2019 at 08:05:41PM -0500, Bruce Dubbs via blfs-dev wrote: > > As best I can tell, our configurations are the same. I do have both the > elogind and mountcgroupfs bootscripts running at startup. The only thing > left that I can tell is that we may have used different build procedures. > Have you modified anything from the book's instructions? AFAIK I used the > exact instructions in the book. No flags or other changes. > Thanks. For the moment, both the mountcgroupfs and elogind bootscripts have been started. I've been trying to add myself to the wheel group, but not necessarily successfully: ken@plexi ~$ groups users lp audio video cdrom lpadmin netdev ken@plexi ~$ grep 'wheel' /etc/group* /etc/group:wheel:x:97:7:ken /etc/group-:wheel:x:97:ken ken@plexi ~$ Those are after rebooting following 'usermod'. For the moment, I've gone back to 4755 perms because test results in this position will be meaningless. As you suspect, I have built almost everything optimised for cheap hardening and speed (-O3 -march-native -D_FORTIFY_SOURCE=2 -fstack-protector-strong ) Giving up for the moment. Thanks anyway. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/2019 8:14 PM, Ken Moffat via blfs-dev wrote: On Sun, Aug 25, 2019 at 12:42:12AM +, DJ Lucas via blfs-dev wrote: At this point, I'm clearly out of my depth, and I will not be updating further systems (nor reviewing if the kernel config for elogind is adequate, nor if the mountcgroupfs and elogind bootscripts are really needed) unless I can understand where my build/usage of elogind is failing. ĸen The seat actions are at /usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ Thanks, but not on this system :-( ken@plexi ~ $ls /usr/share/polkit-1/actions/ com.mesonbuild.install.policy org.freedesktop.policykit.policy org.freedesktop.color.policy org.gtk.vfs.file-operations.policy org.freedesktop.policykit.examples.pkexec.policy org.x.xf86-video-intel.backlight-helper.policy ĸen Okay, so that file should be installed by elogind: dj@lfsdt2 [ /sources/elogind-241.3/build ]$ ls Dest/usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/19 7:12 PM, Ken Moffat via blfs-dev wrote:
On Sat, Aug 24, 2019 at 05:57:10PM -0500, Bruce Dubbs via blfs-dev wrote:
On 8/24/19 4:38 PM, Ken Moffat via blfs-dev wrote:
Assuming that the reply to my earlier post (should I be in the input
group?) is 'no', can somebody please spare some time to explain how
authorisation via polkit (which I think is the intended route to
gaining access to /dev/input/event*) is supposed to work ?
I've built polkit with the patch for elogind. Both dbus and elogind
have been started.
After some discussion, we determined that dbus must be built twice due to
circular dependencies:
dbus
pam
elogind
dbus
...
polkit
Yes, and it was.
First question: should polkitd be running (i.e. visible in ps aux)
or does it only fire up to respond to dbus, and then shut down again
?
There is no boot script for polkit, so something needs to start it. I'm not
sure what does that, but we have polkit as a runtime dependency of
xorg-server.
Yes, but (assume I'm thick, if it helps) - on a working desktop, is
polkitd visible (ps aux | grep polkit) ?
Second question: how is the user who started xorg authenticated by
polkitd ?
Looking at the man pages, all rules files in /etc/polkit-1/rules.d
and /usr/share/polkit-1/rules.d are processed in lexical order (in
the event of a tie, the file in /etc is processed first). But on
this completed system I only have three files in those two
directories:
I note that /etc/polkit-1/rules.d/50-default.rules has
polkit.addAdminRule(function(action, subject) {
return ["unix-group:wheel"];
});
On my system, I am a member of the wheel group, but I didn't add that
recently. It is legacy. Are you a member of the wheel group?
No. I don't really want to be (if ken is running something that
needs root access, he ought to have to 'su' to remind him of the
dangers ;) But I do remember there was _something_ about being a
member of the wheel group in the past few months, although I don't
remember the details.
Will try that later.
I have not yet built gnome and for me /usr/share/polkit-1/rules.d is empty.
Yes, that is what I would expect.
[snip]
I agree that the interaction of applications, elogind, dbus, pam, and polkit
are complicated.
I think the real problem is that the details have never explicitly
been spelled out, except perhaps in various elogind 'issues'. In
systemd, of course, it is all integral to one package.
Speaking of pam, in /etc/pam.d/ do you have polkit-1, elogind-user, and
login?
[snip]
yes, copied below:
[snip]
Your pam files look the same as mine.
As best I can tell, our configurations are the same. I do have both the
elogind and mountcgroupfs bootscripts running at startup. The only
thing left that I can tell is that we may have used different build
procedures. Have you modified anything from the book's instructions?
AFAIK I used the exact instructions in the book. No flags or other changes.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sun, Aug 25, 2019 at 12:42:12AM +, DJ Lucas via blfs-dev wrote: > > > At this point, I'm clearly out of my depth, and I will not be > > updating further systems (nor reviewing if the kernel config for > > elogind is adequate, nor if the mountcgroupfs and elogind > > bootscripts are really needed) unless I can understand where my > > build/usage of elogind is failing. > > > > ĸen > > The seat actions are at > /usr/share/polkit-1/actions/org.freedesktop.login1.policy > > --DJ > Thanks, but not on this system :-( ken@plexi ~ $ls /usr/share/polkit-1/actions/ com.mesonbuild.install.policy org.freedesktop.policykit.policy org.freedesktop.color.policy org.gtk.vfs.file-operations.policy org.freedesktop.policykit.examples.pkexec.policy org.x.xf86-video-intel.backlight-helper.policy ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On 8/24/2019 4:38 PM, Ken Moffat via blfs-dev wrote: Assuming that the reply to my earlier post (should I be in the input group?) is 'no', can somebody please spare some time to explain how authorisation via polkit (which I think is the intended route to gaining access to /dev/input/event*) is supposed to work ? I've built polkit with the patch for elogind. Both dbus and elogind have been started. First question: should polkitd be running (i.e. visible in ps aux) or does it only fire up to respond to dbus, and then shut down again ? Second question: how is the user who started xorg authenticated by polkitd ? Looking at the man pages, all rules files in /etc/polkit-1/rules.d and /usr/share/polkit-1/rules.d are processed in lexical order (in the event of a tie, the file in /etc is processed first). But on this completed system I only have three files in those two directories: /etc/polkit/rules.d/50-default-rules which seems to be checking if admin users are in the wheel group, and in /usr/share/polkit-1/rules.d I have org.freedesktop.NetworkManager.rules and org.gtk.vfs.file-operations.rules from building those packages at a later stage. I don't see anything that would cause polkitd to grant access to me via elogind. At this point, I'm clearly out of my depth, and I will not be updating further systems (nor reviewing if the kernel config for elogind is adequate, nor if the mountcgroupfs and elogind bootscripts are really needed) unless I can understand where my build/usage of elogind is failing. ĸen The seat actions are at /usr/share/polkit-1/actions/org.freedesktop.login1.policy --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and polkit
On Sat, Aug 24, 2019 at 05:57:10PM -0500, Bruce Dubbs via blfs-dev wrote:
> On 8/24/19 4:38 PM, Ken Moffat via blfs-dev wrote:
> > Assuming that the reply to my earlier post (should I be in the input
> > group?) is 'no', can somebody please spare some time to explain how
> > authorisation via polkit (which I think is the intended route to
> > gaining access to /dev/input/event*) is supposed to work ?
> >
> > I've built polkit with the patch for elogind. Both dbus and elogind
> > have been started.
>
> After some discussion, we determined that dbus must be built twice due to
> circular dependencies:
>
> dbus
> pam
> elogind
> dbus
> ...
> polkit
>
Yes, and it was.
> > First question: should polkitd be running (i.e. visible in ps aux)
> > or does it only fire up to respond to dbus, and then shut down again
> > ?
>
> There is no boot script for polkit, so something needs to start it. I'm not
> sure what does that, but we have polkit as a runtime dependency of
> xorg-server.
>
Yes, but (assume I'm thick, if it helps) - on a working desktop, is
polkitd visible (ps aux | grep polkit) ?
> > Second question: how is the user who started xorg authenticated by
> > polkitd ?
> >
> > Looking at the man pages, all rules files in /etc/polkit-1/rules.d
> > and /usr/share/polkit-1/rules.d are processed in lexical order (in
> > the event of a tie, the file in /etc is processed first). But on
> > this completed system I only have three files in those two
> > directories:
>
> I note that /etc/polkit-1/rules.d/50-default.rules has
>
> polkit.addAdminRule(function(action, subject) {
> return ["unix-group:wheel"];
> });
>
> On my system, I am a member of the wheel group, but I didn't add that
> recently. It is legacy. Are you a member of the wheel group?
No. I don't really want to be (if ken is running something that
needs root access, he ought to have to 'su' to remind him of the
dangers ;) But I do remember there was _something_ about being a
member of the wheel group in the past few months, although I don't
remember the details.
Will try that later.
>
> I have not yet built gnome and for me /usr/share/polkit-1/rules.d is empty.
>
Yes, that is what I would expect.
> > /etc/polkit/rules.d/50-default-rules which seems to be checking if
> > admin users are in the wheel group, and in
> > /usr/share/polkit-1/rules.d I have
> > org.freedesktop.NetworkManager.rules and
> > org.gtk.vfs.file-operations.rules from building those packages at a
> > later stage.
> >
> > I don't see anything that would cause polkitd to grant access to me
> > via elogind.
> >
> > At this point, I'm clearly out of my depth, and I will not be
> > updating further systems (nor reviewing if the kernel config for
> > elogind is adequate, nor if the mountcgroupfs and elogind
> > bootscripts are really needed) unless I can understand where my
> > build/usage of elogind is failing.
>
> I agree that the interaction of applications, elogind, dbus, pam, and polkit
> are complicated.
>
I think the real problem is that the details have never explicitly
been spelled out, except perhaps in various elogind 'issues'. In
systemd, of course, it is all integral to one package.
> Speaking of pam, in /etc/pam.d/ do you have polkit-1, elogind-user, and
> login? Also:
>
> $ cat system-session
> # Begin /etc/pam.d/system-session
>
> session requiredpam_unix.so
>
> # End /etc/pam.d/system-session
> # Begin elogind addition
>
> session requiredpam_loginuid.so
> session optionalpam_elogind.so
>
> # End elogind addition
>
> -- Bruce
yes, copied below:
# Begin /etc/pam.d/polkit-1
auth includesystem-auth
account includesystem-account
password includesystem-password
session includesystem-session
# End /etc/pam.d/polkit-1
# Begin /etc/pam.d/elogind-user
account requiredpam_access.so
account include system-account
session requiredpam_env.so
session requiredpam_limits.so
session requiredpam_unix.so
session requiredpam_loginuid.so
session optionalpam_keyinit.so force revoke
session optionalpam_elogind.so
auth requiredpam_deny.so
password requiredpam_deny.so
# End /etc/pam.d/elogind-user
# Begin /etc/pam.d/login
# Set failure delay before next prompt to 3 seconds
auth optionalpam_faildelay.so delay=300
# Check to make sure that the user is allowed to login
auth requisite pam_nologin.so
# Check to make sure that root is allowed to login
# Disabled by default. You will need to create /etc/securetty
# file for this module to function. See man 5 securetty.
#auth requiredpam_securetty.so
# Additional group memberships - disabled by default
#auth optionalpam_group.so
# include the default auth settings
auth include system-auth
# check access for the user
account requiredpam_access.so
# include the default account settings
account include system-account
# Set default
Re: [blfs-dev] elogind and polkit
On 8/24/19 4:38 PM, Ken Moffat via blfs-dev wrote:
Assuming that the reply to my earlier post (should I be in the input
group?) is 'no', can somebody please spare some time to explain how
authorisation via polkit (which I think is the intended route to
gaining access to /dev/input/event*) is supposed to work ?
I've built polkit with the patch for elogind. Both dbus and elogind
have been started.
After some discussion, we determined that dbus must be built twice due
to circular dependencies:
dbus
pam
elogind
dbus
...
polkit
First question: should polkitd be running (i.e. visible in ps aux)
or does it only fire up to respond to dbus, and then shut down again
?
There is no boot script for polkit, so something needs to start it. I'm
not sure what does that, but we have polkit as a runtime dependency of
xorg-server.
Second question: how is the user who started xorg authenticated by
polkitd ?
Looking at the man pages, all rules files in /etc/polkit-1/rules.d
and /usr/share/polkit-1/rules.d are processed in lexical order (in
the event of a tie, the file in /etc is processed first). But on
this completed system I only have three files in those two
directories:
I note that /etc/polkit-1/rules.d/50-default.rules has
polkit.addAdminRule(function(action, subject) {
return ["unix-group:wheel"];
});
On my system, I am a member of the wheel group, but I didn't add that
recently. It is legacy. Are you a member of the wheel group?
I have not yet built gnome and for me /usr/share/polkit-1/rules.d is empty.
/etc/polkit/rules.d/50-default-rules which seems to be checking if
admin users are in the wheel group, and in
/usr/share/polkit-1/rules.d I have
org.freedesktop.NetworkManager.rules and
org.gtk.vfs.file-operations.rules from building those packages at a
later stage.
I don't see anything that would cause polkitd to grant access to me
via elogind.
At this point, I'm clearly out of my depth, and I will not be
updating further systems (nor reviewing if the kernel config for
elogind is adequate, nor if the mountcgroupfs and elogind
bootscripts are really needed) unless I can understand where my
build/usage of elogind is failing.
I agree that the interaction of applications, elogind, dbus, pam, and
polkit are complicated.
Speaking of pam, in /etc/pam.d/ do you have polkit-1, elogind-user, and
login? Also:
$ cat system-session
# Begin /etc/pam.d/system-session
session requiredpam_unix.so
# End /etc/pam.d/system-session
# Begin elogind addition
session requiredpam_loginuid.so
session optionalpam_elogind.so
# End elogind addition
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] elogind and polkit
Assuming that the reply to my earlier post (should I be in the input group?) is 'no', can somebody please spare some time to explain how authorisation via polkit (which I think is the intended route to gaining access to /dev/input/event*) is supposed to work ? I've built polkit with the patch for elogind. Both dbus and elogind have been started. First question: should polkitd be running (i.e. visible in ps aux) or does it only fire up to respond to dbus, and then shut down again ? Second question: how is the user who started xorg authenticated by polkitd ? Looking at the man pages, all rules files in /etc/polkit-1/rules.d and /usr/share/polkit-1/rules.d are processed in lexical order (in the event of a tie, the file in /etc is processed first). But on this completed system I only have three files in those two directories: /etc/polkit/rules.d/50-default-rules which seems to be checking if admin users are in the wheel group, and in /usr/share/polkit-1/rules.d I have org.freedesktop.NetworkManager.rules and org.gtk.vfs.file-operations.rules from building those packages at a later stage. I don't see anything that would cause polkitd to grant access to me via elogind. At this point, I'm clearly out of my depth, and I will not be updating further systems (nor reviewing if the kernel config for elogind is adequate, nor if the mountcgroupfs and elogind bootscripts are really needed) unless I can understand where my build/usage of elogind is failing. ĸen -- Adopted by dwarfs, brought up by dwarfs. To dwarfs I'm a dwarf, sir. I can do the rite of k'zakra, I know the secrets of h'ragna, I can ha'lk my g'rakha correctly ... I am a dwarf Captain Carrot Ironfoundersson (in The Fifth Elephant) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
