View previous topic :: View next topic |
Author |
Message |
eminenz Tux's lil' helper
Joined: 16 Jul 2006 Posts: 95
|
Posted: Fri May 10, 2013 9:38 pm Post subject: polkitd eating up 100% cpu on hardened kernel w/o mprotect |
|
|
Hi!
I probably have a very strange problem.
I upgraded to 3.7.5-hardened kernel and udev-200 recently, and did an emerge -e system afterwards.
Normal working was possible until I turned off grsecurity/pax MPROTECT feature in the kernel as I had several problems with it and recompiled the kernel.
Now, WITH LESS security restriction, polkit runs at 100% CPU.
There is only one polkit process if I'm logged in via console, it's many if I'm logged in graphically.
Code: |
PID PPID %CPU USER PR NI VIRT RES SHR S %MEM TIME+ COMMAND
2741 1 11,6 polkitd 20 0 143m 7956 7076 R 0,4 8:17.06 polkitd
2764 1 11,6 polkitd 20 0 134m 7944 7076 R 0,4 8:11.68 polkitd
2795 1 11,6 polkitd 20 0 84440 7940 7076 R 0,4 8:03.26 polkitd
2791 1 11,2 polkitd 20 0 121m 7936 7076 R 0,4 8:07.24 polkitd
2809 1 11,2 polkitd 20 0 144m 7928 7076 R 0,4 8:00.03 polkitd
2699 1 3,3 eminenz 20 0 522m 154m 64m S 7,7 1:57.70 midori
2321 2317 2,3 root 20 0 226m 49m 15m S 2,4 1:12.26 X
6879 1 1,3 eminenz 20 0 339m 25m 20m S 1,3 0:00.68 Terminal
|
I have no idea why polkit goes rampage.
Some maybe relevant versions:
udisks 1.0.4-r5
upower 0.9.16
polkit-0.110
I don't even know where to start looking for the cause. I don't find anything relevant in syslog. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat May 11, 2013 3:11 am Post subject: |
|
|
It might sound stupid, but I just got rid of *kit in the end, as I'd already got rid of semantic-desktop on KDE and switched from KMail to mutt. There's a great write-up on removing *kit here.
Sorry if that's no help. I noticed you were using a lightweight browser, so might want a more lightweight desktop too. (KDE is now running as slickly as 3.5 used to. Combined with "Attach as Tab" in 4.9+ it's become a much better place to work again, thankfully.) |
|
Back to top |
|
|
eminenz Tux's lil' helper
Joined: 16 Jul 2006 Posts: 95
|
Posted: Sat May 11, 2013 8:41 am Post subject: |
|
|
Thank you so much for that info!
Im using xfce4 and getting rid of *kit and u* and systemd right now
after playing around a little more i found
Code: | May 11 09:44:41 exitus kernel: [ 88.565341] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/upowerd[upowerd:2290] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
May 11 09:44:41 exitus kernel: [ 88.568888] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/gvfs-gdu-volume-monitor[gvfs-gdu-volume:2294] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/dbus-daemon[dbus-daemon:2293] uid/euid:1000/1000 gid/egid:100/100
May 11 09:44:41 exitus kernel: [ 88.647071] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/gdu-notification-daemon[gdu-notificatio:2255] uid/euid:1000/1000 gid/egid:100/100, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
May 11 09:45:06 exitus kernel: [ 113.629478] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/gvfs-gdu-volume-monitor[gvfs-gdu-volume:2324] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/dbus-daemon[dbus-daemon:2323] uid/euid:1000/1000 gid/egid:100/100
May 11 09:45:06 exitus kernel: [ 113.633488] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/upowerd[upowerd:2315] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
May 11 09:45:31 exitus kernel: [ 138.723748] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/upowerd[upowerd:2334] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
May 11 09:45:56 exitus kernel: [ 163.793326] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/upowerd[upowerd:2342] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
May 11 09:47:11 exitus kernel: [ 238.917634] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/upowerd[upowerd:2359] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 |
directly after a reboot.
As I don't think i'll have to deal with *kit and u{disk,power} any longer, it'll be resolved in an hour when that mess has left my system.
In case anybody else stumbles over this, it seems to be a limits.conf-related thing and is fixed there:
https://forums.gentoo.org/viewtopic-t-839738-highlight-limits+conf.html?sid=8ea2e3b8ee0c34e0d7361db319be42a2 |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun May 12, 2013 10:33 am Post subject: |
|
|
eminenz wrote: | Thank you so much for that info!
Im using xfce4 and getting rid of *kit and u* and systemd right now :) |
Hey, that's great, you're very welcome :) I hope it works out for you: if not feel free to ask on that thread.
Just for future, it's better to make topic links with the topic tag: Code: | [topic=839738]topic link[/topic] |
That's better as the link is a lot shorter, and doesn't include your session-id.
In this case, you can use a post tag Code: | [post=6473249]post tag[/post] | to link directly to the post which answers the issue. The url for those can be copied from the small envelope next to the "Posted: <date>" then you just delete everything but the id.
HTH,
steveL. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun May 12, 2013 11:02 am Post subject: |
|
|
eminenz wrote: | it seems to be a limits.conf-related thing |
So it is essentially related with pam. Since you are using hardened, I am wondering why you use pam. Of course, if you need access over ldap or something similar there is probably no way around it, but otherwise: since you are just recompiling to get rid of *kit you might perhaps think about to get rid of pam as similarly to polkit it is essentially just an additional layer which thus might contain bugs...
Unofortunately lightdm does not seem to work without pam (at least, according to the ebuild) but kdm does. |
|
Back to top |
|
|
eminenz Tux's lil' helper
Joined: 16 Jul 2006 Posts: 95
|
Posted: Sun May 12, 2013 9:12 pm Post subject: |
|
|
well it's a rather strange thing with my box and pam.
I managed to get along without pam quite a while until some change prevented locking the display on xscreensaver with setuid set), if xscreensaver was not compiled with pam.
I wrote a mail to the developer of xscreensaver who essentially said your situation is not the common xscreensaver situation and pam was designed to fix this, it's not an xscreensaver issue.
I didn't find another way to be able to lock my display again then to install pam (I tried multiple days...). I don't use it with any other application, though (global useflag -pam). |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon May 13, 2013 7:20 pm Post subject: |
|
|
I'm much happier relying on pam than anything else. Combined with sudo (and a small amount of visudo), I really don't see the need for more on a desktop.
It's also much easier to put together a convenient setup for someone else, when the base is nice and simple in configuration, and doesn't change every 6 months.
Admins can also do a lot with pam for bigger setups, but that's not my use-case, nor is it whom most of the "convenience" layers are aimed at. _________________
creaker wrote: | systemd. It is a really ass pain |
update - "a most excellent portage wrapper"
#friendly-coders -- We're still here for you™ ;) |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu May 16, 2013 12:54 pm Post subject: |
|
|
eminenz wrote: | I managed to get along without pam quite a while until some change prevented locking the display on xscreensaver with setuid set |
I would say if you want screenlocking this is a valid use case for pam. Sure, the screenlocker could implement something, but I can understand if the developer says that this is better left to some standard tool. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|