Bug 65575

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.