pam_limits

[IcedEarth]

Hallo,

bin neu hier im Forum. Naja das stimmt so nicht ganz. Ich lese schon eine ganze Weile mit und benutze fleißig die Suchfunktion. Allerdings bin ich auf ein Problem gestoßen, wo mir weder noch das Forum, noch meine eigenen Kentnisse weiterhelfen.

Folgende Meldungen auf meinem vServer stehen in der Datei /var/log/auth.log

Jul 14 17:09:01 vserver pam_limits[4387]: setrlimit limit #11 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0

Eine Suche bei Google brachte mich auf einen Bug in der OpenSSH Implementierung. Dieser Bug soll aber schon seit 2005 gefixt sein. Ich habe derzeit die Version (1:4.3p2-9etch2) [security] laufen.

Jetzt etwas detaillierter... Dieser Fehler kommt IMMER, wenn der user root einen cron Job ausführt. Also egal welcher Cron Job auf dem System ausgeführt wird, kommt diese Meldung. Soweit konnte ich das ganze schon einschränken. Ich konnte die Fehlermeldung auch schon durch auskommentieren wegbekommen, allerdings halte ich dies für den falschen Weg.

Wird dies auskommentiert, geht es:
nano /etc/pam.d/cron
# session required pam_limits.so

nano /etc/pam.d/ssh
# session required pam_limits.so

Eventuell hat jemand eine Idee oder einen guten Workaround. Beim auskommentieren ist mir nicht ganz wohl...

Gruß Iced

[IcedEarth]

Mhhhh keiner eine Idee?

[antiplex]

hiho!

ich hab bei mir dasselbe problem und habe nun auch schon einige zeit damit verbracht, da durchzusteigen. ich muss gestehen, dass mir das gesamte pam-geraffel nicht so wirklich einleuchtet; warum da irgendwelche limits geändert werden usw...

meine suche hat folgendes ergeben:
- da war in der tat mal ein bug, mittlerweile behoben.
- tritt nur bei vservern auf und ist wohl nur kosmetischer natur (log-einträge), nicht aber funktionsrelevant.
- infos zu setrlimit http://linux.about.com/library/cmd/blcm ... rlimit.htm

wenn ich die info zu setrlimit so überfliege, dämmert mir, woher die problematik rührt. setrlimit verändert sehr grundlegende systemparameter wie maximal erlaubte cpu-zyklen oder speicherallokierung. dadurch könnte (wenns denn ginge) ein gastsystem quasi die ganze power des servers an sich reissen.
unser virtualisiertes debian weiss aber nichts von seiner virtuellen realität (bissl wie in matrix ) und denkt, dass root (uid=0) das eigentlich schon dürfen sollte. da kommts dann wohl zum konflikt und es folgt ein log-eintrag.

ich würde meinen cron jobs auch gerne abgewöhnen, dass sie an derlei systemparametern rumändern, hab aber keinen blassen schimmer wie...

greez - anti

NACHTRAG: ich hab mir soeben mal noch mittels '# ulimit -Ha' ein paar grundlegende systembeschränkungen angeschaut; dabei ist mit aufgefallen, dass zum beispiel das maximum für 'nice' '0' ist, und nicht -20 wie theoretisch möglich; auch 'max rt priority' ist auf 0, allerdings kann ich damit nichts anfangen; was ist denn die rt-prio?
nun geht leider aus dem log-eintrag nicht hervor, welcher wert per 'setrlimit' versucht wird zu verändern, ein nice-wert von -1 würde ja prinzipiell schon sinn machen.
jetzt frage ich mich nur, ob ich die ulimits anpassen soll (sofern möglich?) oder ob man irgendwie in '/etc/security/limits.conf' rummurksen sollte, wie unter '/etc/pam.d/cron' angemerkt (Sets up user limits, please define limits for cron tasks through /etc/security/limits.conf) wird.
hat da wer ahnung?

[gms]

Willkommen im Forum!

meine suche hat folgendes ergeben:
...
- tritt nur bei vservern auf und ist wohl nur kosmetischer natur (log-einträge), nicht aber funktionsrelevant.

richtig, daher wäre eine einfache Lösung, diese Logeinträge rauszufiltern. Wenn ihr den "rsyslog" oder "syslog-ng" verwendet, geht das relativ einfach.
Das Auskommentieren von "session required pam_limits.so " in "/etc/pam.d/cron" ist auch eine akzeptable Lösung, vorallem wenn ihr keine relevanten Anpassungen in der "/etc/security/limits.conf" vorhabt.

NACHTRAG: ich hab mir soeben mal noch mittels '# ulimit -Ha' ein paar grundlegende systembeschränkungen angeschaut; dabei ist mit aufgefallen, dass zum beispiel das maximum für 'nice' '0' ist, und nicht -20 wie theoretisch möglich; auch 'max rt priority' ist auf 0, allerdings kann ich damit nichts anfangen; was ist denn die rt-prio?

root kann seine Limits aber normlerweise auch wieder höher setzen. Das "rt-prio" steht für "Realtime Priorität", beinflußt also das Scheduling der Realtime-Prozesse.

nun geht leider aus dem log-eintrag nicht hervor, welcher wert per 'setrlimit' versucht wird zu verändern, ein nice-wert von -1 würde ja prinzipiell schon sinn machen.

das -1 wird wahrscheinlich für "unlimited" also "kein Limit" stehen

Gruß
gms

[antiplex]

Willkommen im Forum!

ja danke vielmals !

richtig, daher wäre eine einfache Lösung, diese Logeinträge rauszufiltern. Wenn ihr den "rsyslog" oder "syslog-ng" verwendet, geht das relativ einfach.

leider nein, ich verwende den stinknormalen syslogd (v 1.4.1)

Das Auskommentieren von "session required pam_limits.so " in "/etc/pam.d/cron" ist auch eine akzeptable Lösung, vorallem wenn ihr keine relevanten Anpassungen in der "/etc/security/limits.conf" vorhabt.

zum einen glaube ich, dass ich anpassungen diesbezüglich in der tat nicht benötige, zum anderen scheint es mir so, als könnte ich gar keine anpassungen in der '/etc/decurity/limits.conf' vornehmen; hab das vorhin mal ausprobiert mit harmlosen werten ('* hard nice 0'), worauf nach einem reboot ein weiterer eintrag im auth-log auftaucht, allerdings mit anderen (in diesem fall nachvollziehbaren) parametern: 'setrlimit limit #13 to soft=19, hard=0 failed: Operation not permitted; uid=0 euid=0'. von daher kann ich auf die limits bzw pam für cron wohl verzichten...

root kann seine Limits aber normlerweise auch wieder höher setzen. Das "rt-prio" steht für "Realtime Priorität", beinflußt also das Scheduling der Realtime-Prozesse.

auch das wollte ich mal ausprobieren; das lässt sich doch für nice z.b. per '# ulimit -He 2' bewerkstelligen, oder? bei mir kommt da allerdings 'bash: ulimit: max nice: cannot modify limit: Die Operation ist nicht erlaubt' ... und ja, ich bin als root drauf.

auf jeden fall mal vielen dank für die antwort; langsam näher ich mich ja immerhin mal an die thematik an...
ach genau, ich hab da noch ne ganz brauchbare erläuterung der pam-geschichte gefunden:
http://www.selflinux.org/selflinux/html ... eit05.html

[gms]

das lässt sich doch für nice z.b. per '# ulimit -He 2' bewerkstelligen, oder? bei mir kommt da allerdings 'bash: ulimit: max nice: cannot modify limit: Die Operation ist nicht erlaubt' ... und ja, ich bin als root drauf.

probiere einmal "ulimit -He unlimited", ob das unter einem vServer funktioniert, weiß ich allerdings auch nicht

[antiplex]

nope, ergebnis wie vorher auch.
ergo akzeptiere ich das einfach mal als vserver-einschränkung. ist in meinem fall jetzt nicht weiter schlimm, aber gut zu wissen...

jetzt ist mir aber noch eines unklar: wenn ich die verwendung des pam-moduls 'pam-limits.so' in der '/etc/pam.d/cron' auskommentiere, dann wird schon weiter pam durch cron verwendet, nur das finetuning per limits fällt flach, oder?

EDIT: ich nehme mal an, dass die '@include'-anweisungen sowie die 'auth required irgendwas.so' zeile die pam-grundauthentifizierung sicherstellen. was würde aber zum beispiel passieren, wenn ich komplett alles auskommentieren würde, also cron quasi nakt ohne pam-zugriff dastehen würde? nicht, dass ich darin irgendeinen sinn sehe, nur so rein informativ... /EDIT

danke nochmal für deine hilfe,
anti

[gms]

jetzt ist mir aber noch eines unklar: wenn ich die verwendung des pam-moduls 'pam-limits.so' in der '/etc/pam.d/cron' auskommentiere, dann wird schon weiter pam durch cron verwendet, nur das finetuning per limits fällt flach, oder?

ja, bei einer Standardkonfiguration wird dann noch immer pam-unix.so verwendet

[gms]

EDIT: ich nehme mal an, dass die '@include'-anweisungen sowie die 'auth required irgendwas.so' zeile die pam-grundauthentifizierung sicherstellen. was würde aber zum beispiel passieren, wenn ich komplett alles auskommentieren würde, also cron quasi nakt ohne pam-zugriff dastehen würde? nicht, dass ich darin irgendeinen sinn sehe, nur so rein informativ... /EDIT

das kommt ganz auf die Cron-Implementierung drauf an. Es könnte dann z.B über die /etc/passwd bzw /etc/group, oder die Funktionen "getpwent" die uid und gid für die User-Cron Prozesse ermittelt werden und mit den setuid/setgid Funktionen ein Impersonate durchgeführt werden.

[antiplex]

das kommt ganz auf die Cron-Implementierung drauf an. Es könnte dann z.B über die /etc/passwd bzw /etc/group, oder die Funktionen "getpwent" die uid und gid für die User-Cron Prozesse ermittelt werden und mit den setuid/setgid Funktionen ein Impersonate durchgeführt werden.

ah, interessant! es existiert also wahrscheinlich eine fallbackvariante (je nach compile-options etc).
da taucht mir eine weitere frage auf, die dann jetzt allerdings so ziemlich gar nichts mehr mit dem ursprünglichen thema zu tun hat:
mit welchen rechten laufen cron-jobs? wenn cron intern forkt und dann per 'exec' irgendwas zur ausführung bringt, so läuft das ja erstmal mit denselben rechten wie der cron-prozess, zumindest sofern da kein set-uid-bit gesetzt ist. und wenn ich das richtig verstehe kann mir 'getpwent' doch nur die felder zu dem eintrag des users, der den jeweiligen code ausführt liefern?
ich kenn mich da wie man merkt wohl nicht sonderlich gut aus, ein grober einblick würde mich aber schon interessieren.

EDIT nach nochmal drüber nachdenken hab ich soeben realisiert, dass der cron-daemon ja üblicherweile mit root-rechten laufen dürfte udn dadurch ja natürlich schon für seine frok-childs die uid/gid setzen kann und sich wohl dann an die besitzverhältnisse der auszuführenden datei anpasst. *erleuchtung* \EDIT

ein hoch auf gms's wissensreichtum