Re: OT: df command

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Wed, 18 Sep 2013 10:06:25 +0200 (CEST)

Manfred Lotz wrote:
> > > # mkdir -p /a/b
> > > # chmod 755 /a/b
> > >
> > > # mount /dev/... /a/b
> > > # chmod 700 /a/b
> > >
> > > # mkdir -p /a/b/c
> > > # chmod 755 /a/b/c
> > >
> > > # mount /dev/... /a/b/c
> > > # chmod 700 /a/b/c
> > >
> > > nun hatte ich als nicht root user bei df beide an /a/b/ und a/b/c
> > > angezeigte Filesysteme angezeigt bekommen, ohne irgendeine
> > > Fehlermeldung.
> > >
> > > In deinem Beispiel hätte man dann chmod 700 / machen müssen, was
> > > man sicher auch nicht für einen Test wirklich machen will.
> >
> > Auch in dem Fall sollte ein einfaches "df" alle Dateisysteme
> > anzeigen.
>
> Meinst du /a/b/c? Wenn /a/b 700 hat, wie oben, dann sollte ein df ohne
> Parameter ein perm denied geben für /a/b/c. /a/b sollte natürlich
> angezeigt werden.

Nein, bei "df" werden alle angezeigt (es sei denn, man ist
in einem Jail).

> > Aber hast Du mal "df /a/b" und "df /a/b/c" probiert?
> > Letzteres sollte "Permission denied" liefern.
>
> Yep, das passiert dann auch.

Da geht es jetzt ans Eingemachte ...

Bei "df" (ohne Parameter) wird einfach die komplette Liste
aller Mounts des Kernels ausgegeben. Dies erledigt der
Syscall getfsstat(2). Diese Liste wird vom Kernel separat
von Dateisystemen verwaltet und beinhaltet daher keine
Permissions. Daher kann sie auch von nicht privilegierten
Prozessen vollständig abgefragt werden. Wie man der
Manpage von getfsstat(2) entnehmen kann, sind dort auch
keine Fehlercodes für Zugriffsprobleme vorgesehen (EPERM
oder EACCES).

Wird dagegen bei df ein Verzeichnis angegeben, muss dessen
Pfad zunächst im Dateisystem aufgelöst werden, um den
statfs(2)-Syscall ausführen zu können. Daher kommen in
diesem Fall die Permissions im Dateisystem zum Tragen.

Interessant wird es auch, wenn man df zwar ohne Verzeichnis,
aber mit einer Filteroption aufruft, z.B. "df -t nodevfs".
Dann wird Dir zwar /a/b/c angezeigt, aber zusätzlich auch
eine Warnung, die etwa so aussieht:

df: /a/b/c stats possibly stale

Das liegt daran, dass df in diesem Fall zunächst die gesamte
Mount-Liste mit getfsstat(2) abruft, dann aber in einem
zweiten Durchgang die gewünschten Einträge herausfiltert
und dabei nochmal ein statfs(2) auf jeden einzelnen Eintrag
ausführt, was bei /a/b/c schiefgeht. Hier gibt df dann die
Warnung aus und zeigt die (möglicherweise veralteten) Daten
von /a/b/c an, die der vorherige Aufruf von getfsstat(2)
geliefert hat.

Aber so langsam verlieren wir uns in obskuren Details, die
in der Praxis kaum eine Relevanz haben. Es ist auch gut
denkbar, dass df unter AIX anders implementiert ist und
sich anders verhält als unter FreeBSD. Das ist weitgehend
nicht standardisiert.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart
FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd
"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
        -- Doug Gwyn
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 18 Sep 2013 - 10:06:36 CEST

search this site