I think the bug should be in a polkit product, but it is not available in the choice. During the test of systemd , I just see that my current user has not enough permissions. Infact, I can't manage networkmanager connections, I can't suspend, I can't mount via udisks but loginctl says that I'm an active user. ago@arcadia ~ $ loginctl --no-pager show-session $XDG_SESSION_ID | grep Active Active=yes I completely killed consolekit from my system, and I'm using logind. The systemd support is enabled globally. To install and configure systemd, I followed the wiki: http://wiki.gentoo.org/wiki/Systemd I know that probably you don't have enough info, just feel free to ask whatever you need.
It's probably a good idea to report bugs like this to Gentoo first.
(In reply to comment #1) > It's probably a good idea to report bugs like this to Gentoo first. Obviously done. No useful notice in more than one week.
Can you provide the basics? 1) What _exactly_ are you doing, what are the expected and actual results? 2) Are there any related messages in system logs (from systemd, polkit*, the service that is asking for permissions)?
(In reply to comment #3) > Can you provide the basics? Already done, do you prefer any other translations? > 1) What _exactly_ are you doing, what are the expected and actual results? I'm expected to do certain operations, like suspend, mount an usb pendrive or edit the networkmanager connection, authorized by polkit. It does not happen and it should be. > 2) Are there any related messages in system logs (from systemd, polkit*, the > service that is asking for permissions)? no
@systemd team I discovered the exactly problem. Actually I'm using a gentoo hardened system and the module CONFIG_GRKERNSEC_PROC doing its job prevents the correct behavior of systemd. Did any of you try systemd with grsecurity?
(In reply to comment #5) > I discovered the exactly problem. Actually I'm using a gentoo hardened > system and the module CONFIG_GRKERNSEC_PROC doing its job prevents the > correct behavior of systemd. Could you be a bit more explicit? What is CONFIG_GRKERNSEC_PROC doing and why is breaking systemd? > Did any of you try systemd with grsecurity? Probably not.
(In reply to comment #6) > Could you be a bit more explicit? What is CONFIG_GRKERNSEC_PROC doing and > why is breaking systemd? Sure. You can find the info about grsecurity here http://grsecurity.net/ The explanation of the module is: If you say Y here, the permissions of the /proc filesystem will be altered to enhance system security and privacy. You MUST choose either a user only restriction or a user and group restriction. Depending upon the option you choose, you can either restrict users to see only the processes they themselves run, or choose a group that can view all processes and files normally restricted to root if you choose the "restrict to user only" option. NOTE: If you're running identd or ntpd as a non-root user, you will have to run it as the group you specify here.
We don't support out-of-tree kernel modules that majorly impact the /proc API. Closing. We can reinvestigate this if the grsecurity patches have been merged into the upstream kernel.
Please reopen. This could be replicated on vanilla kernel by ”mount /proc -oremount,hidepid=1”
(In reply to comment #9) > Please reopen. This could be replicated on vanilla kernel by ”mount /proc > -oremount,hidepid=1” Well, this sounds useful, but I don't see how we can support this, we need access to the PID directory of the sender of messages, to collect metadata, there's really no way around it. This also needed by policykit and similar software. I think the current concept of hidepid=1 is really not compatible with how operating systems work these days. Unfortunately hidepid=1 is implemented as a global boolean setting, instead of a per-/proc-instance setting. If it was the latter would neatly support it in systemd, by simply enabling it for specific services, by placing them in a mount namespace of their own and then mounting a /proc instance with the flag set into them. But, unfortunately, hidepid=1 applies to all /proc instances the same way currently, so we cannot do that. (This is fixable though in the kernel, but nobody has done that yet).
> we need access to the PID directory of the sender of messages, to collect metadata, there's really no way around it. Could kdbus help with this?
(In reply to maxim.suraev from comment #11) > > we need access to the PID directory of the sender of messages, to collect metadata, there's really no way around it. > > Could kdbus help with this? I don't see how.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.