From netch@ustas.carrier.kiev.ua  Mon Jun 21 11:51:55 2004
Return-Path: <netch@ustas.carrier.kiev.ua>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 3C90416A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 21 Jun 2004 11:51:55 +0000 (GMT)
Received: from ustas.carrier.kiev.ua (ustas.carrier.kiev.ua [193.193.193.6])
	by mx1.FreeBSD.org (Postfix) with ESMTP id BF57A43D1F
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 21 Jun 2004 11:51:53 +0000 (GMT)
	(envelope-from netch@ustas.carrier.kiev.ua)
Received: (from netch@localhost)
	by ustas.carrier.kiev.ua (8.12.11/8.11.3) id i5LBoaw7022311;
	Mon, 21 Jun 2004 14:50:36 +0300 (EEST)
	(envelope-from netch)
Message-Id: <200406211150.i5LBoaw7022311@ustas.carrier.kiev.ua>
Date: Mon, 21 Jun 2004 14:50:36 +0300 (EEST)
From: Valentin Nechayev <netch@lucky.net>
Reply-To: Valentin Nechayev <netch@lucky.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: df fails to check fs type with -t and inaccessible mount point
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         68165
>Category:       bin
>Synopsis:       df fails to check fs type with -t and inaccessible mount point
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    csjp
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 21 12:00:43 GMT 2004
>Closed-Date:    Wed Jul 21 05:27:26 GMT 2004
>Last-Modified:  Wed Jul 21 05:27:26 GMT 2004
>Originator:     Valentin Nechayev
>Release:        FreeBSD 4.10-RELEASE i386
>Organization:
Lucky Net Ltd.
>Environment:
System: FreeBSD 4.10-RELEASE

>Description:

Full df output for this host says:

Filesystem  1K-blocks    Used    Avail Capacity  Mounted on
/dev/da0s1a    496111  261683   194740    57%    /
/dev/da0s2e   1977238 1006815   812244    55%    /var
/dev/da0s3e  14515912 5078856  8275784    38%    /var/Backups/important
/dev/da1s1e   4320972 1500900  2474395    38%    /var/Backups/backups
procfs              4       4        0   100%    /proc
/dev/da2s4e  32676496 7719364 22343016    26%    /var/Backups/d2

Monitoring hook runs as nobody; `nobody' has no access inside /var/Backups.
When run `df', all is OK. When run `df -t ufs' as nobody, it says:

Filesystem  1K-blocks    Used   Avail Capacity  Mounted on
/dev/da0s1a    496111  261683  194740    57%    /
/dev/da0s2e   1977238 1006818  812241    55%    /var
/dev/da0s3e  14515912 5078856 8275784    38%    /var/Backups/important
/dev/da1s1e   4320972 1500900 2474395    38%    /var/Backups/backups
procfs              4       4       0   100%    /proc

so it loses /var/Backups/d2 (which is ufs) and prints /proc (which is not ufs).

With access inside /var/Backups, it prints correct:

Filesystem  1K-blocks    Used    Avail Capacity  Mounted on
/dev/da0s1a    496111  261683   194740    57%    /
/dev/da0s2e   1977238 1006815   812244    55%    /var
/dev/da0s3e  14515912 5078856  8275784    38%    /var/Backups/important
/dev/da1s1e   4320972 1500900  2474395    38%    /var/Backups/backups
/dev/da2s4e  32676496 7719364 22343016    26%    /var/Backups/d2

Also, it works OK when /proc is mounted _after_ /var/Backups/d2,
regardless of right to access inside /var/Backups;
but remounting /proc before /var/Backups/d2 triggers the bug again.

>How-To-Repeat:

See above.

>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->csjp 
Responsible-Changed-By: csjp 
Responsible-Changed-When: Sat Jun 26 07:56:05 GMT 2004 
Responsible-Changed-Why:  
I will take this one.  This PR brings up a more interesting 
problem, if the parent directory of a mount point does not 
have execute-search permissions, should the user be able 
to access any information about the mount point in the 
first place, as the path to the mount-point itself exposes 
a filename within a restricted directory. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=68165 
State-Changed-From-To: open->closed 
State-Changed-By: csjp 
State-Changed-When: Wed Jul 21 05:25:47 GMT 2004 
State-Changed-Why:  
Commited a patch which teaches df how to deal with 
statfs failing. This should solve the problem. 
Thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=68165 
>Unformatted:
