Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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, 14:44 GMT-4
Last edited by Grigorios Bouzakis (dolby) - Friday, 09 May 2008, 15:11 GMT-4
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Jan de Groot (JGC)
Operating System All
Severity Critical
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

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

Comment by Aaron Griffin (phrakture) - Thursday, 08 May 2008, 14:51 GMT-4
If the config stuff is actually there, I wonder if we're just missing something as simple as a configure flag.
Comment by name withheld (Gullible Jones) - Thursday, 08 May 2008, 15:17 GMT-4
Maybe it has to be made executable? I did notice that all the stuff in pam.d was -x.
Comment by Jan de Groot (JGC) - Thursday, 08 May 2008, 17:30 GMT-4
This is because gdm doesn't include pam_limits.so in the supplied pam file.
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 08:39 GMT-4
I'll try adding that and see how it works.
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 08:40 GMT-4
Nope, pam_limits.so is definitely there.

#%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.
Comment by Jan de Groot (JGC) - Friday, 09 May 2008, 08:52 GMT-4
Try putting pam_limits.so below pam_unix.so. If that works out, I'll fix it for the next gdm update.
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 08:54 GMT-4
This is worse than I thought. Right now I'm using the CLI login, not GDM, and have nproc limited to 256; and a bash forkbomb still freezes my machine very quickly. It looks as though PAM stuff is being disobeyed across the board.
Comment by Jan de Groot (JGC) - Friday, 09 May 2008, 09:10 GMT-4
Please supply the /etc/security/limits.conf you're using. On my system, adding things to limits.conf works fine without problems.
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 09:20 GMT-4
* hard maxlogins 4
* soft nproc 256
* hard nproc 512
* - rtprio 0
* - nice 0
@audio - rtprio 65
@audio - nice -10
@audio - memlock 40000
Comment by Jan de Groot (JGC) - Friday, 09 May 2008, 09:28 GMT-4
What does ulimit -a show after logging in?
Comment by name withheld (Gullible Jones) - Friday, 09 May 2008, 12:57 GMT-4
core file size (blocks, -c) 0
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
Comment by name withheld (Gullible Jones) - Tuesday, 03 June 2008, 19:07 GMT-4
Okay, I can confirm that rlimits stuff at least is not being obeyed. Recent experimentation with jackd as user got me this from a Wine sound test:

$ 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.
Comment by name withheld (Gullible Jones) - Tuesday, 03 June 2008, 19:08 GMT-4
^^^ Also, I was starting jackd with the -R option, so that side of things was definitely correct.
Comment by name withheld (Gullible Jones) - Wednesday, 04 June 2008, 18:22 GMT-4
With rtprio 99 and nice -20, I'm still unable to use realtime. This is very bad.

Loading...