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
Re: [blfs-dev] Xorg under blfs-9.0/elogind
On 8/18/2019 12:05 AM, DJ Lucas via blfs-dev wrote: On 8/17/2019 8:53 PM, Ken Moffat via blfs-dev wrote: On Sat, Aug 17, 2019 at 08:40:23AM +, DJ Lucas via blfs-dev wrote: On August 16, 2019 4:36:41 PM CDT, Bruce Dubbs via blfs-dev wrote: I ran into a bit of a problem when starting Xorg. It came up but I had no mouse or keyboard input. There was also a problem finding Xorg.0.log to see what was happening. It is in ~/.local/share/xorg/Xorg.0.log. That is documented in the Testing and Configuration section for systemd. I will change it so it is reflected in both books now that we are using elogind. I had not started dbus or elogind. After starting those, the xorg input still did not work. I then rebooted and the mouse and keyboard worked fine. I think a logout and login may have been sufficient, but I'm not sure. I'm not sure how to address this. It would only be a one-time issue. Should we recommend a reboot before starting xorg for the first time? logout/in? That's usually when I reboot from chroot for the first time. I'm unsure yet whether we can rid ourselves of mountcgroupfs and elogind bootscripts. Start the dbus bootscript. startx. Works perfectly (intel video), and the log is in /var/log/Xorg.0.log. Summary: for me, the bootscripts for mountcgroupfs and elogind are not required, that matches what Pierre discovered the other week. Cool! That's second confirmation. I won't comment on whether we should rid ourselves of them this close to release. Sorry I wasn't able to get back to it earlier. Since there seems to be a problem for Bruce: did you build Xorg before ever booting the new system ? (Apoligies if that is mentioned upthread). I'm guessing that building the whole desktop in chroot before the first boot might be a problem. This would hold true for me as well. I build through Xorg in chroot, then reboot and use a text mode browser to continue, and my results are as yours. Alternatively, the problem might be with non-kms video displays such as nvidia. I was thinking that since your last message. I got fixated on the bootscripts and went off on a tangent that I simply couldn't let go of. I do that sometimes, a lot actually. I've managed to put it aside, but I'm still itching to get back to it (I didn't trap a couple of unforeseen errors and it will require some minor refactoring to truly be distro agnostic). That's why I like the long goals of the project. I know I said I'd do this last week, but I'm going to acquire a lower level nVidia card tomorrow and see if I fare the same as Bruce. I know we are functional now, thanks to everyone's attention on this, and that we can proceed now. I feel better about that, but I want to put these lingering questions (Xorg log) to bed before release. --DJ So this was also a non-starter for me. It just worked out of the box with Nouveau driver on an older build. For reference, console output is from an SSH session for simplicity (as dlcuas is not my regular user): dlucas@lfsdt2 [ ~ ]$ groups dlucas dlucas@lfsdt2 [ ~ ]$ ls -l /var/log/Xorg.0.log -rw-r--r-- 1 root dlucas 34375 Aug 24 16:36 /var/log/Xorg.0.log dlucas@lfsdt2 [ ~ ]$ grep EE /var/log/Xorg.0.log [ 115.703] Current Operating System: Linux lfsdt2 5.1.3 #1 SMP PREEMPT Tue May 21 19:34:09 CDT 2019 x86_64 (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 115.712] (EE) Failed to load module "nv" (module does not exist, 0) [ 115.713] (EE) Failed to load module "vesa" (module does not exist, 0) [ 115.716] (EE) [drm] Failed to open DRM device for (null): -22 [ 115.803] (II) Initializing extension MIT-SCREEN-SAVER dlucas@lfsdt2 [ ~ ]$ grep nouveau /var/log/Xorg.0.log [ 115.712] (==) Matched nouveau as autoconfigured driver 0 [ 115.712] (II) LoadModule: "nouveau" [ 115.712] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so [ 115.712] (II) Module nouveau: vendor="X.Org Foundation" [ 115.715] (II) [drm] nouveau interface version: 1.3.1 [ 115.802] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau [ 115.802] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau [ 115.830] (II) AIGLX: Loaded and initialized nouveau The full log is at: http://www.linuxfromscratch.org/~dj/Xorg.0.log dlucas@lfsdt2 [ ~ ]$ ls -l /usr/bin/Xorg -rwxr-xr-x 1 root root 273 Jun 1 09:43 /usr/bin/Xorg dlucas@lfsdt2 [ ~ ]$ ls -l /usr/libexec/Xorg.wrap -rwsr-xr-x 1 root root 30696 Jun 1 09:43 /usr/libexec/Xorg.wrap dlucas@lfsdt2 [ ~ ]$ ls -l /usr/libexec/Xorg -rwxr-xr-x 1 root root 18121256 Jun 1 09:43 /usr/libexec/Xorg root [ /home/dj ]# lspci | grep -i nvidia 07:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2) 07:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) So, at at this point, I'm ready to throw my hands up. Failing somebody else digging though everything that's been posted thus far, I'm good with just puting back the suid bit. In the event that
[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
Re: [blfs-dev] ModemManager in sysv
On Fri, Aug 23, 2019 at 09:27:43PM -0500, Douglas R. Reno via blfs-dev wrote: > > On 8/23/19 8:31 PM, Ken Moffat via blfs-dev wrote: > > On Fri, Aug 23, 2019 at 02:49:15AM +0100, Ken Moffat via blfs-dev wrote: > > > With the book's current instructions, ModemManager (which appears to > > > now be _required_ for geoclue, but maybe I'm misunderstanding the > > > meson options for geoclue) fails to build: > > > [...] > > > checking for LIBSYSTEMD... no > > > checking for LIBSYSTEMD_LOGIN... no > > > configure: error: libsystemd or libsystemd-login development headers are > > > required > > > [...] > > > I've now managed to > > > build it using the following (based on gentoo) : > > > > > > LIBSYSTEMD_LOGIN_CFLAGS=`pkg-config --cflags "libelogind"` \ > > > LIBSYSTEMD_LOGIN_LIBS=`pkg-config --libs "libelogind"` \ > > > ./configure --prefix=/usr \ > > > (etc). > > > > > > I've no idea if it works, and I see that the build was not verbose - > > > but I don't really have a use for MM, or even for geoclue (unless it > > > turns out to be the magic bullet for epiphany), just trying to check > > > that things build. > > > > > > ĸen > > After running a verbose build, and a verbose DESTDIR install, > > followed by ldd on all the libs in the DESTDIR, I think that for > > the sysv book elogind is just a build dependency, i.e. it doesn't > > actually link to it. > > > > But I have no use for ModemManager, except that geoclue seems to > > require it. Not sure if I should put this in the sysv book ? > > > > ĸen > > > The primary reason why ModemManager needs elogind is so that it can gain > access to device nodes for manipulating GSM/3G/4G/ (upcoming) 5G modems. It > performs the same way that systemd-logind does in that case > Informative, but I don't have any connection to a mobile phone from this desktop, and anyway I still can't get elogind to work. I'll leave this for anyone who cares about gnome on sysv. ĸ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
[blfs-dev] elogind : should I be in the input group ?
I'm still totally failing to get elogind to allow me to use non-suid Xorg. I can see that elogind starts, e.g. after reinstating suid on Xorg this morning: Aug 24 07:00:50 plexi dbus-daemon[1224]: [system] Activating service name='org.freedesktop.login1' requested by ':1.0' (uid=0 pid=1418 comm="/bin/login -- ") (using servicehelper) Aug 24 07:00:50 plexi klogd: <38>[ 13.185042] elogind-daemon[1427]: New seat seat0. Aug 24 07:00:50 plexi klogd: <38>[ 13.185828] elogind-daemon[1427]: Watching system buttons on /dev/input/event1 (Power Button) Aug 24 07:00:50 plexi klogd: <38>[ 13.200267] elogind-daemon[1427]: Watching system buttons on /dev/input/event0 (Power Button) Aug 24 07:00:50 plexi klogd: <38>[ 13.248290] elogind-daemon[1427]: Watching system buttons on /dev/input/event11 (SEM USB Keyboard) Aug 24 07:00:50 plexi klogd: <38>[ 13.248349] elogind-daemon[1427]: Watching system buttons on /dev/input/event12 (SEM USB Keyboard Consumer Control) Aug 24 07:00:50 plexi klogd: <38>[ 13.248402] elogind-daemon[1427]: Watching system buttons on /dev/input/event13 (SEM USB Keyboard System Control) Aug 24 07:00:50 plexi dbus-daemon[1224]: [system] Successfully activated service 'org.freedesktop.login1' Aug 24 07:00:50 plexi klogd: <38>[ 13.333089] elogind-daemon[1427]: New session c1 of user ken. But I never get permission to use /dev/input/event* so the Xorg log in ~/,local has a series of [ 128.874] (**) Option "Device" "/dev/input/event1" [ 128.874] (**) Option "_source" "server/udev" [ 128.879] (EE) xf86OpenSerial: Cannot open device /dev/input/event1 Permission denied. [ 128.879] (II) event1: opening input device '/dev/input/event1' failed (Permission denied). [ 128.879] (II) event1 - failed to create input device '/dev/input/event1'. [ 128.879] (EE) libinput: Power Button: Failed to create a device for /dev/input/event1 [ 128.879] (EE) PreInit returned 2 for "Power Button" [ 128.879] (II) UnloadModule: "libinput" [ 128.879] (II) event1: opening input device '/dev/input/event1' failed (Permission denied). [ 128.879] (II) event1 - failed to create input device '/dev/input/event1'. [ 128.879] (EE) libinput: Power Button: Failed to create a device for /dev/input/event1 [ 128.879] (EE) PreInit returned 2 for "Power Button" [ 128.879] (II) UnloadModule: "libinput" [ 128.879] (II) config/udev: Adding input device Video Bus (/dev/input/event2) [ 128.879] (**) Video Bus: Applying InputClass "keyboard-all" [ 128.879] (**) Video Bus: Applying InputClass "libinput keyboard catchall" [ 128.879] (II) Using input driver 'libinput' for 'Video Bus' [ 128.879] (**) Video Bus: always reports core events [ 128.879] (**) Option "Device" "/dev/input/event2" [ 128.879] (**) Option "_source" "server/udev" [ 128.879] (EE) xf86OpenSerial: Cannot open device /dev/input/event2 Permission denied. [ 128.879] (II) event2: opening input device '/dev/input/event2' failed (Permission denied). and similarly for event0 (keyboard-all), events11..13 (keyboard-catchall), event14 (mouse). I've been assuming that a normal user should NOT be in the input group, but there are "fixes" for similar problems by adding the normal user to the input group. Is that the right thing to do in BLFS, and if so, where have I missed noticing it ? (grepping for 'group' or 'input' in the xml finds far too many matches, e.g. for userinput tags). ĸ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
