From nobody@FreeBSD.org  Mon Jun  1 17:13:34 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 76A5810656FC
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  1 Jun 2009 17:13:34 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 6433A8FC1F
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  1 Jun 2009 17:13:34 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n51HDYOH025269
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 1 Jun 2009 17:13:34 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n51HDYow025268;
	Mon, 1 Jun 2009 17:13:34 GMT
	(envelope-from nobody)
Message-Id: <200906011713.n51HDYow025268@www.freebsd.org>
Date: Mon, 1 Jun 2009 17:13:34 GMT
From: Roberto Grassi <r.grassi-at-obicon.it@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: 100.chksetuid and non local filesystem mounted on subdirs
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         135160
>Category:       conf
>Synopsis:       100.chksetuid and non local filesystem mounted on subdirs
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 01 17:20:04 UTC 2009
>Closed-Date:    Mon Jun 08 10:43:26 UTC 2009
>Last-Modified:  Mon Jun 08 10:43:26 UTC 2009
>Originator:     Roberto Grassi
>Release:        7.2-STABLE
>Organization:
>Environment:
FreeBSD nessus.obicon.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed May 27 10:26:48 CEST 2009     root@ux-builder:/usr/obj/usr/src/sys/vmware-esx35  i386

>Description:
The find options in the 100.chksetuid script will traverse mount points found as local (ufs or zfs) but the test if they are local is done on the mount point itself, no further checks are done for non local file system file below them.
In the case a mount point is a subdir of a local mount point, the find will traverse it, causing the traverse go to other machine.
Example:
with this mount command output :
   /dev/da0d on /usr
   10.10.10.10:/usr/ports on /usr/ports
   10.10.10.11:/usr/src on /usr/src
the command inside 100.chksetuid 
   find -sx $MP /dev/null -type f \
     \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \
     ...
will go on 10.10.10.10 and 10.10.10.11 server.

Moreover, in the case the NFS, SMBFS or other non local FS server did not respond all the periodic checks will not finish.
>How-To-Repeat:
use mountpoints for non local FS in subdirectory of /.
>Fix:
--- 100.chksetuid.orig  2008-12-27 19:07:31.000000000 +0100
+++ 100.chksetuid       2009-06-01 19:01:51.000000000 +0200
@@ -46,4 +46,5 @@
        MP=`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
        find -sx $MP /dev/null -type f \
+           \( -fstype ufs -or -ftype zfs \) \
            \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \
            \( -perm -u+s -or -perm -g+s \) -exec ls -liTd \{\} \+ |


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: brian 
Responsible-Changed-When: Tue Jun 2 06:44:32 UTC 2009 
Responsible-Changed-Why:  
I'll take this - it's probably a similar problem to pr 122811 

http://www.freebsd.org/cgi/query-pr.cgi?pr=135160 
State-Changed-From-To: open->feedback 
State-Changed-By: brian 
State-Changed-When: Tue Jun 2 08:38:20 UTC 2009 
State-Changed-Why:  
Can the submitter re-check to see if this is indeed the case? 

# find -sx /usr /dev/null -type f | wc -l 
# umount /usr/ports /usr/src 
# find -sx /usr /dev/null -type f | wc -l 

On my 7.2 system this returns the same number.  The -x switch 
avoids the mountpoint traversal (as advertised). 

Does the above return two different numbers on your system? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=135160 

From: Roberto Grassi <r.grassi@obicon.it>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: conf/135160: 100.chksetuid and non local filesystem mounted on subdirs
Date: Fri, 5 Jun 2009 14:39:58 +0200

 I done the tests and I will change the problem description as follows:
 
 ------- here the required tests output -------
 ux-hylafax <<root>> 101 ~ >mount -t nfs 172.27.9.8:/usr/src /usr/src
 ux-hylafax <<root>> 102 ~ >mount -t nfs 172.27.9.8:/usr/obj /usr/obj
 ux-hylafax <<root>> 103 ~ >find -sx /usr /dev/null -type f | wc -l
    26400
 ux-hylafax <<root>> 104 ~ >umount /usr/src
 ux-hylafax <<root>> 105 ~ >umount /usr/obj
 ux-hylafax <<root>> 106 ~ >find -sx /usr /dev/null -type f | wc -l
    26400
 ux-hylafax <<root>> 107 ~ >mount -t nfs 172.27.9.8:/usr/src /usr/src
 ux-hylafax <<root>> 108 ~ >mount -t nfs 172.27.9.8:/usr/obj /usr/obj
 ux-hylafax <<root>> 109 ~ >cd /usr/src
 ux-hylafax <<root>> 110 /usr/src >find . -type f | wc -l
    39532
 ux-hylafax <<root>> 111 /usr/src >
 ux-hylafax <<root>> 111 /usr/src >mount
 /dev/da0s1a on / (ufs, local)
 devfs on /dev (devfs, local)
 /dev/da0s1d on /usr (ufs, local, soft-updates)
 /dev/da0s1f on /var (ufs, local, soft-updates)
 172.27.9.8:/usr/src on /usr/src (nfs)
 172.27.9.8:/usr/obj on /usr/obj (nfs)
 ux-hylafax <<root>> 112 /usr/src >cd
 ux-hylafax <<root>> 113 ~ >ping 172.27.9.8
 PING 172.27.9.8 (172.27.9.8): 56 data bytes
 ^C
 --- 172.27.9.8 ping statistics ---
 3 packets transmitted, 0 packets received, 100.0% packet loss
 ux-hylafax <<root>> 114 ~ >find -sx /usr /dev/null -type f | wc -l
 nfs server 172.27.9.8:/usr/obj: not responding
 ^C^C^C^C^Cnfs server 172.27.9.8:/usr/obj: not responding
 nfs server 172.27.9.8:/usr/obj: not responding
 ^Cnfs server 172.27.9.8:/usr/obj: not responding
 
 *** FINAL System shutdown message from root@ux-hylafax ***
 System going down IMMEDIATELY
 
 ------------- end of output transcript ---------
 
 As you stated the command "find -sx /usr /dev/null -type f | wc -l" returne=
 d=20
 the same result with mounted and unmounted NFS file systems.
 
 Now, if the NFS server give up (in the transcript the command #113 was run=
 =20
 after the shutdown of the 172.27.9.8 server), the find command will stale.
 
 Even if I user the  "\( -fstype ufs -or -fstype zfs \)" the command will=20
 stale.
 In both cases I tried to kill the PID of the find commands with every signa=
 l=20
 (from 0 to 31), but  no one was successful in killing the process.
 
 The only option to stop the find is to reboot the server or to wait the NFS=
 =20
 server come back on line (in case of hw failure can be a problem as=20
 happened)
 
 Maybe, the PR as to be change to other category.
 
 
 
State-Changed-From-To: feedback->closed 
State-Changed-By: brian 
State-Changed-When: Mon Jun 8 10:39:50 UTC 2009 
State-Changed-Why:  
The investigation went something like this: 

> On Fri, 5 Jun 2009 08:06:08 -0700 Brian Somers <brian@FreeBSD.org> wrote:   
[.....] 
>Unformatted:
 >> This is interesting.  I suspect that the find is hanging when it stats 
 >> the mountpoint, even though it never recurses into the NFS 
 >> filesystem.  I'll look into investigating this later today and will get 
 >> back to you. 
 >>  
 >> Thanks for the feedback.   
 
 > So after a little bit of investigation, and a little thinking, it turns 
 > out that this *is* the problem.   
 
 > Using "-x" and using "! -fstype local -prune -o ..." both result 
 > in find(1) needing to stat(2) each file to even determine that 
 > it's remote or on a different filesystem.  If the stat(2) hangs 
 > indefinitely, then the whole daily run will just wait that long.   
 
 > You really only have one option if your remote mounts are 
 > unreliable, and that is to mount them "soft" so that call such 
 > as stat(2) will eventually time out if the remote system doesn't 
 > respond.   
 
 > I think it would be inappropriate to add exclusions to the find 
 > list too - we would then need to add the same facility to a 
 > whole slew of other system scripts.   
 
 > I'm going to close this PR as I think it has no useful actions 
 > that need to be done.  Would you agree?  I'll quote my 
 > reasoning from this email.   
 
 > Cheers.   
 
 
 Hi Brian. 
 I agree with you about the problem investigation results and about  
 the suggestion to not modify the system scripts. 
 The soft option to mount points is the right one. 
 
 I will add that I will use this option in any case. In fact the NFS 
 server that had the hardware error, had a 500+ days of uptime.  
 So I used to consider that a reliable server. 
 The events suggest me to no more consider any NFS server as reliable, 
 especially if I have to reboot other server that mount NFS directories. 
 This would be a best practice (for me, obviously). 
 
 You can close the PR. 
 
 Many thanks for all, 
 Roberto 
 
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=135160 
