FS#10374 - [gdm] causes system to disobey /etc/security/limits.conf
Attached to Project:
Arch Linux
Opened by name withheld (Gullible Jones) - Thursday, 08 May 2008, 18:44 GMT
Last edited by Jan de Groot (JGC) - Friday, 19 June 2009, 06:44 GMT
Opened by name withheld (Gullible Jones) - Thursday, 08 May 2008, 18:44 GMT
Last edited by Jan de Groot (JGC) - Friday, 19 June 2009, 06:44 GMT
|
Details
Description:
If GDM is used as a login manager, PAM stuff (including /etc/security/limits.conf) is not used. This makes the system vulnerable to forkbombs (and probably other hazards), as well as ruining realtime for users. Because of the security risks here and since GDM might see use in office environments or on workstations, I'm flagging this critical. Additional info: * pam 1.0.1-1, gdm 2.20.1-2 * There's config stuff for gdm and gnome-screensaver in /etc/pam.d. It doesn't contain anything on limits.conf AFAICT, but it makes me think this may be solvable for Arch instead of requiring me to go upstream. Steps to reproduce: 1. Set a limit on nproc in limits.conf. 2. Set up GDM as your login manager and use it to launch your desktop. 3. Open a terminal, run a forkbomb, and watch your system crash in spite of your limits.conf settings. |
This task depends upon
Closed by Jan de Groot (JGC)
Friday, 19 June 2009, 06:44 GMT
Reason for closing: Not a bug
Additional comments about closing: ulimit settings get applied by logins from gdm.
Friday, 19 June 2009, 06:44 GMT
Reason for closing: Not a bug
Additional comments about closing: ulimit settings get applied by logins from gdm.
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so
auth required pam_unix.so
account required pam_unix.so
session required pam_limits.so <-- requisite entry
session required pam_unix.so
password required pam_unix.so
Not nice.
* soft nproc 256
* hard nproc 512
* - rtprio 0
* - nice 0
@audio - rtprio 65
@audio - nice -10
@audio - memlock 40000
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 30
file size (blocks, -f) unlimited
pending signals (-i) 4020
max locked memory (kbytes, -l) 40000
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 65
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 256 <--- Strange, that's what it's supposed to be. WTF?
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
$ winecfg
cannot lock down memory for RT thread (Cannot allocate memory)
With this in limits.conf:
@audio - rtprio 80
@audio - nice -10
@audio - memlock 250000
There's definitely something fishy here.
cannot lock down memory for RT thread (Cannot allocate memory)
was reported pretty commonly when doing realtime audio work w/ jackd and the latest kernel. It seems that some that some have resolved this issue by downgrading. I am running 2.6.24 w/ ingos rt21 patches and using the slim-pam package from AUR w/ proper results. Hope this is of use.
cannot lock down memory for RT thread (Cannot allocate memory)
was reported pretty commonly when doing realtime audio work w/ jackd and the latest kernel. It seems that some that some have resolved this issue by downgrading. I am running 2.6.24 w/ ingos rt21 patches and using the slim-pam package from AUR w/ proper results. Hope this is of use.
So this issue, can be closed?