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 required pam_unix.so > > # End /etc/pam.d/system-session > # Begin elogind addition > > session required pam_loginuid.so > session optional pam_elogind.so > > # End elogind addition > > -- Bruce yes, copied below: # Begin /etc/pam.d/polkit-1 auth include system-auth account include system-account password include system-password session include system-session # End /etc/pam.d/polkit-1 # Begin /etc/pam.d/elogind-user account required pam_access.so account include system-account session required pam_env.so session required pam_limits.so session required pam_unix.so session required pam_loginuid.so session optional pam_keyinit.so force revoke session optional pam_elogind.so auth required pam_deny.so password required pam_deny.so # End /etc/pam.d/elogind-user # Begin /etc/pam.d/login # Set failure delay before next prompt to 3 seconds auth optional pam_faildelay.so delay=3000000 # 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 required pam_securetty.so # Additional group memberships - disabled by default #auth optional pam_group.so # include the default auth settings auth include system-auth # check access for the user account required pam_access.so # include the default account settings account include system-account # Set default environment variables for the user session required pam_env.so # Set resource limits for the user session required pam_limits.so # Display date of last login - Disabled by default #session optional pam_lastlog.so # Display the message of the day - Disabled by default #session optional pam_motd.so # Check user's mail - Disabled by default #session optional pam_mail.so standard quiet # include the default session and password settings session include system-session password include system-password # End /etc/pam.d/login and # Begin /etc/pam.d/system-session session required pam_unix.so # End /etc/pam.d/system-session # Begin elogind addition session required pam_loginuid.so session optional pam_elogind.so # End elogind addition I do note that elogind is always labelled as optional, and I assume that is so that remote logins are permitted (although I never normally have an openssh server on desktop machines). ĸ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