Seltsames Berechtigungsproblem

E

-eraz-

Tripel-As
Hallo,

kann mir das einer erklären ?(
Ich habe einen User (operating) in RHEL 5.2 angelegt, ganz normal mit dem Befehl 'useradd' + passwort vergeben -> fertig.

Nun habe ich folgendes Verhalten:
1.) Der User darf die Maschine neu starten, wenn man sich direkt mit ihm einloggt. (siehe Screenshot 1)
2.) Der User darf die Maschine nicht neu starten, wenn man sich zuvor mit root einloggt und dann ein su- operating macht. (siehe Screenshot 2)
 

Anhänge

  • Screenshot1.JPG
    Screenshot1.JPG
    31,4 KB · Aufrufe: 27
  • Screenshot2.JPG
    Screenshot2.JPG
    23,1 KB · Aufrufe: 25
Zuletzt bearbeitet:
Steht doch da: nur root darf einen Reboot machen.
Wenn du aber das Nutzerkonto mit "su - operating" wechselst, darfst du als Nutzer "operating" kein Reboot machen, weil du eben nicht root bist.
 
@aspire_5652
Nochmal genau lesen bitte :rolleyes:

Bei beiden Versionen, führe ich den reboot mit dem User 'operating' aus!
 
Oh, sorry. Das hatte ich übersehen.

edit: und was passiert wenn du das Nutzerkonto nur mit "su operating" wechselst
 
Zuletzt bearbeitet:
Wie sieht dein /etc/pam.d/reboot aus?

Bei mir ist "/usr/bin/reboot" ein Link auf ein "/usr/bin/consolehelper"; die Manualpage davon sagt, dass man dieses Programm über verschiedene Links (wie z.B. reboot, shutdown etc.) aufrufen kann, und dass die Authentifizierung dann über den PAM-Stack erfolgt ...

Gruss
 
das pam.d file sieht bei mir so aus:
Code:
#%PAM-1.0
auth       sufficient   pam_rootok.so
auth       required     pam_console.so
#auth       include     system-auth
account    required     pam_permit.so
Kannst du mir erklären was die einzelnen Zeilen bedeuten?

reboot ist ein link in /sbin und führt bei mir zu /sbin/halt
 
Hi,

du könntest zunächst mal noch abchecken, ob in beiden Fällen wirklich dasselbe "reboot" aufgerufen wird; könnte ja sein, dass in einem Fall /sbin/reboot (-> /sbin/halt), im anderen Fall /usr/bin/reboot (-> /usr/bin/consolehelper) aufgerufen wird, was dann auch schon mal unterschiedliche Auswirkungen haben könnte.

In beiden Fällen (also bei "halt" und bei "consolehelper") wird im PAM-Stack das Modul "pam_console.so" eingebunden. Wie bei allen PAM-Modulen bekommst du Info dazu aus der Manual-Page (hier also "man pam_console"), und die sagt u.a.:

"pam_console.so is designed to give users at the physical console (virtual terminals and local xdm-managed X sessions by default, but that is configurable) capabilities that they would not otherwise have, and to take those capabilities away when the are no longer logged in at the console."

Ich vermute jetzt einfach mal ganz frech, dass du darüber die Berechtigung, "reboot" auszuführen bekommst, wenn du dich direkt als "operating" user einloggst. (Das sollte dann also auch mit jedem anderen Login funktionieren). Wenn du dich als "root" einloggst, und dann mit "su" in den "operating" Account wechselst, bist du nicht mehr direkt auf der lokalen Konsole eingeloggt, damit fällt die Authentifizierung über pam_console.so flach ...

Das Ganze wie immer reine Vermutung, scheint aber irgendwie Sinn zu machen ... und solange uns keiner das Gegenteil beweist :) ...

Grüsse
 
Deine Vermutung scheint völlig richtig zu sein! :)

Diese pam_console ist mir ganz neu, sehr gut das ich die jetzt auch kenne. Sie hat jedenfalls verursacht, dass User die sich direkt an der Konsole anmelden, mit höheren Rechten ausgestattet werden. Bei uns wäre das aber eher nachteilig, da es sich um virtualisierte Server handelt und somit mehr Menschen physischen Zugriff auf die Konsole haben. Allerdings habe ich bisher noch keinen wirklichen Weg gefunden dieses "feature" zu deaktivieren. Ich hab mal alle Files aus /etc/security/console.apps entfernt. Das löst das Problem zwar, aber richtig sauber kommt mir das nicht vor. Kennst du da einen geeigneten Weg?
 
Die Files aus /etc/security/console.apps zu entfernen sieht mir nach einer sauberen und einfachen Möglichkeit aus, den Zugriff entsprechend einzuschränken. Änderungen am PAM-Stack haben meiner traurigen Erfahrung nach sonst oft Auswirkungen, die man dann erst auf den zweiten Blick sieht :)

Gruss
 
Das mit dem löschen der Files ist leider keine so gute Idee. Nach einem Update des Kernels hat er mir wieder alle Files neu erstellt. Kennt jemand ne Möglichkeit wie man das sonst noch abdrehen könnte?

/edit
Gibt es vielleicht ein Möglichkeit nur root den Login auf die Konsole zu erlauben?
 
Zuletzt bearbeitet:

Ähnliche Themen

Samba 3.6.25 - OpenLDAP Setup

script sshpass

Keine grafische Oberfläche (Debian Installation)

CentOS 7: Falsche Metric bei regelbasiertem Routing nach Server-Reboot

Samba4 AD DC - Kerberos: Failed to decrypt PA-DATA

Zurück
Oben