Re: OT: df command

From: Manfred Lotz <manfred.lotz(at)arcor.de>
Date: Mon, 16 Sep 2013 07:46:23 +0200

On Sun, 15 Sep 2013 23:11:21 +0200 (CEST)
Oliver Fromme <olli(at)lurza.secnetix.de> wrote:

> Manfred Lotz wrote:
> > Ich habe Zugriff auf ein z/OS mainframe system, welches auch eine
> > Unix komponente hat, genannt z/OS Unix System Services. Dieses
> > Unix ist POSIX compliant laut IBM.
> >
> > Dort verhält sich das df command so, dass man für bestimmte
> > Mountpoints ein permission denied bekommt, also keine Information
> > angezeigt bekommt, wenn man keine rx Permission hat für das
> > Verzeichnis oben drüber.
>
> Das ist normales, zu erwartendes Verhalten unter jedem UNIX-
> bzw. POSIX-System. POSIX bzw. SUS sagt dazu:
>
> »The df utility shall write the amount of available space
> and file slots for file systems on which the invoking user
> has appropriate read access.«
>
> df(1) tut im Grunde nichts weiter, als den syscall statfs(2)
> aufzurufen und dessen Informationen auszugeben. Die Manpage
> von statfs(2) ist bezüglich der Permissions eindeutig:
>
> [EACCES] Search permission is denied for a component
> of the path prefix of path.
>
> D.h. alle Komponenten oberhalb des angegebenen Pfades müssen
> für den aufrufenden Benutzer das x-Bit haben, anderenfalls
> gibt es EACCESS (errno 13).
>
> Es sollte auch darauf hingewiesen werden, dass die Rückgabe-
> werte von statfs(2) -- und somit doe Ausgabe von df(1) --
> auch durch andere Umstände eingeschränkt oder modifiziert
> werden können. Bei FreeBSD ist das z.B. in Jails der Fall
> (man kann dies per sysctl einstellen). Und das ist auch
> richtig so, denn Prozessen in einem Jail geht es nichts an,
> welche Mounts es anderswo gibt; hierdurch könnten sensitive
> Daten verraten werden.
>
> Ebenso ist es mit den Permissions. Wenn ein Benutzer keine
> x-Permission für ein Vezeichnis hat. dann gehen ihn auch
> keine Details der ggf. darunter befindlichen Mounts an.
>
> Leider kann man statfs/df nicht generell für Benutzer
> abschalten (ohne dass man gleich alle in ein Jail steckt,
> was ja noch andere "Nebeneffekte" hat). Es gibt durchaus
> Situationen, wo das wünschenswert wäre. Es ist allerdings
> nicht schwer, den Kernel entsprechend zu modifizieren.
>

Erstmal vielen Dank für deine Ausführungen.

Ich habe in der Zwischenzeit noch ein interessanter Phänomen
festgestellt.

Wenn es /a/b/c gibt und wenn an /a/b als auch an /a/b/c ein Filesystem
gemountet ist, dann zeigt ein df auf z/OS USS beide Filesysteme an,
auch wenn der Aufrufer keine Permission (0) hat für /a/b. Für /a hat er
natürlich eine 5.

Das ist doch dann eigentlich als Bug zu sehen, oder übersehe ich da was?

-- 
Manfred
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 16 Sep 2013 - 07:46:34 CEST

search this site