From rsb@sac.sfbay.sun.com Thu Sep 27 14:15:19 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8RLFJg5023016 for ; Thu, 27 Sep 2007 14:15:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8RLCDMi006005; Thu, 27 Sep 2007 14:12:14 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JP100609PKCV700@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Sep 2007 14:12:12 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JP10002APKCMP60@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Sep 2007 14:12:12 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l8RLCBhn015460; Thu, 27 Sep 2007 14:12:11 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8RLFEe9023009; Thu, 27 Sep 2007 14:15:14 -0700 (PDT) Received: (from rsb@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l8RLFE3x023005; Thu, 27 Sep 2007 16:15:14 -0500 (CDT) Date: Thu, 27 Sep 2007 16:15:14 -0500 (CDT) From: Rich.Brown@sun.com Subject: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] To: PSARC-ext@sun.com Cc: Rich.Brown@sun.com, Thomas.Haynes@sun.com, nfs-mars-iteam@sun.com Message-id: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 8043 I'm sponsoring the following fast-track for Tom Haynes. The timer is set for Thursday, 4 Oct, 2007. This case seeks patch binding (to match PSARC 2007/416). Rich Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Add S_IFTRIGGER to st_mode 1.2. Name of Document Author/Supplier: Author: Thomas Haynes 1.3 Date of This Document: 27 September, 2007 4. Technical Description == PROBLEM OVERVIEW nftw(3C) is a routine in libc which is the "new file tree walk". It recursively calls walk() to traverse a directory tree. One main consumer of it is find(1). There are several flags that control how walk() behaves: FTW_MOUNT directs walk() not to cross mountpoints FTW_PHYS directs walk() not to follow symbolic links. The walk() routine uses stat() to test each component that it encounters to ensure that it does not violate the requested behavior. The following code snippet succinctly captures the security test and the window of opportunity: struct stat statPre; struct stat statFile; DIR *pdir; stat(szPath, &statPre); pdir = opendir(szPath); fstat(pdir->dd_fd, &statFile); if (statPre.st_ino != statFile.st_ino || statPre.st_dev != statFile.st_dev) { return(EAGAIN); } There is a window between the stat() and opendir() calls when the user might move directory contents (an innocent case we need to avoid) or use a symlink to get outside of the directory hierarchy (a security breach). If the results of the stat() do not match those of the fstat(), then assume that there is some problem and return to the caller. find(1) will for example report: find: cannot open /mnt: Resource temporarily unavailable A problem with this test occurs when the filesystem is of type "autofs" (PSARC 1992/024). In that case, the directory entry, whose name is given by szPath, is a trigger mount - a mount occurs when the directory is entered. By definition, getting attributes on the directory (i.e., stat()) does not constitute entering the directory, but the opendir() does, which triggers an autofs mount. This leads to a false positive case. The code is not able to detect that a trigger mount occured beneath it - the st_ino and st_dev are expected to not match. As expected, if the user were to immediately retry the application, it would now succeed. The mount has been established and the results from the stat() will match the fstat(). The current code addresses this by doing a strcmp() on st_fstype to determine if it is an autofs filesystem (see fix 6198351). If so, then statPre is refreshed after the opendir(). This is safe in that the kernel owns the contents of the autofs filesystem. If we add the test from the current code for ntfw()/walk(), the code snippet would now look like this: struct stat statPre; struct stat statFile; DIR *pdir; stat(szPath, &statPre); pdir = opendir(szPath); if (statPre.st_fstype[0] == 'a' && strcmp(statPre.st_fstype, "autofs") == 0) { /* * this dir is on autofs */ fstat(pdir->fd->dd_fd, &statPre) } fstat(pdir->dd_fd, &statFile); if (statPre.st_ino != statFile.st_ino || statPre.st_dev != statFile.st_dev) { return(EAGAIN); } With the addition of mirror mounts for NFSv4 (see PSARC 2007/416), we have another case where trigger mounts can cause a false positive. Also note that other NFSv4 features, such as referrals and migration will employ trigger mounts as the integral interface to remote filesystems. We could once again try checking the st_fstype for "nfs4" to for exception checking, but this check will fail for these reasons: 1) st_fstype for "nfs3" and "nfs4" is truncated to "nfs" for backwards compatibility in 3rd party applications. I.e., this would lead to us allowing exemptions for all directory entries on all versions of nfs. The problem is that we can only allow exemptions for directories which are "nfs4" and mirror mount trigger points. 2) All nfs filesystems are not strictly controlled in the kernel as with the autofs filesystem. I.e., it is possible for an user application to mangle the directory tree. The point here is that an autofs filesystem is not directly writeable by the user. The only objects in an autofs filesystem are automount trigger points, and then cannot be manipulated. The user can not move directory hierarchies around in an autofs filesystem. So walk() can be a bit relaxed. With a nfs filesystem, walk() does not have that luxury. === PROPOSED SOLUTION The solution is to determine if the directory is a trigger mount before calling opendir(). If so, then we refresh statPre. In order to do this, we propose to add a new bit, S_IFTRIGGER, to the st_mode field of the struct stat to identify the trigger mount. In particular, we would add to sys/stat.h: #define S_IFTRIGGER 0x20000 /* Operations can trigger a mount */ #define S_ISTRIGGER(mode) (((mode)&0xF0000) == 0x20000) By keeping S_IFTRIGGER above S_IFMT, we keep any conflicts from occurring. I.e., we need to be able to detect an entry is both S_IFTRIGGER and S_IFDIR. Also, S_IFTRIGGER would only be set in the kernel. It would not be stored on disk. The code snippet would now look like this: struct stat statPre; struct stat statFile; DIR *pdir; stat(szPath, &statPre); pdir = opendir(szPath); if (S_ISTRIGGER(statPre.st_mode)) { stat(szPath, &statPre); } fstat(pdir->dd_fd, &statFile); if (statPre.st_ino != statFile.st_ino || statPre.st_dev != statFile.st_dev) { return(EAGAIN); } === EXPORTED INTERFACE TABLE |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== | |This | | Committed |Document | S_IFTRIGGER | | | New bit value S_ISTRIGGER() | | | and test macro | | | for st_mode field | | | in struct stat === MAN PAGE UPDATE TO stat(2) Existing stat(2): st_mode The mode of the file as described for the mknod() function. In addition to the modes described on the mknod(2) manual page, the mode of a file can also be S_IFSOCK if the file is a socket, S_IFDOOR if the file is a door, S_IFPORT if the file is an event port, or S_IFLNK if the file is a symbolic link. S_IFLNK can be returned either by lstat() or by fstat() when the AT_SYMLINK_NOFOLLOW flag is set. Proposed change: st_mode The mode of the file as described for the mknod() function. In addition to the modes described on the mknod(2) manual page, the mode of a file can also be S_IFSOCK if the file is a socket, S_IFDOOR if the file is a door, S_IFPORT if the file is an event port, S_IFTRIGGER if the file is a trigger mount point, or S_IFLNK if the file is a symbolic link. S_IFLNK can be returned either by lstat() or by fstat() when the AT_SYMLINK_NOFOLLOW flag is set. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Thu Sep 27 14:24:13 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8RLODvu023148 for ; Thu, 27 Sep 2007 14:24:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8RLL8ei008534; Thu, 27 Sep 2007 14:21:08 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JP10072VPZ8F800@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Sep 2007 14:21:08 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JP1000R4PZ7MV60@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Sep 2007 14:21:08 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8RLL2UW014556; Thu, 27 Sep 2007 17:21:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l8RLL2IJ014553; Thu, 27 Sep 2007 17:21:02 -0400 (EDT) Date: Thu, 27 Sep 2007 17:21:02 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, Thomas.Haynes@sun.com, nfs-mars-iteam@sun.com Message-id: <18172.7870.360336.68521@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> Status: RO Content-Length: 984 Rich.Brown@Sun.COM writes: > The code snippet would now look like this: > > struct stat statPre; > struct stat statFile; > DIR *pdir; > > stat(szPath, &statPre); > pdir = opendir(szPath); > > if (S_ISTRIGGER(statPre.st_mode)) { > stat(szPath, &statPre); > } > > fstat(pdir->dd_fd, &statFile); > > if (statPre.st_ino != statFile.st_ino || > statPre.st_dev != statFile.st_dev) { > return(EAGAIN); > } If doing the stat() call after opendir() works correctly for trigger points, why would it not work for all other object types? I don't quite see what the stat-after-opendir tells you that the fstat() does not. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Thomas.Haynes@Sun.COM Thu Sep 27 19:01:13 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8S21CVW027467 for ; Thu, 27 Sep 2007 19:01:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l8S1w4Ym012573; Fri, 28 Sep 2007 09:58:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JP2001012SU4Y00@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Sep 2007 18:58:06 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JP200K452STA820@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Sep 2007 18:58:05 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8S1w5Jc021829; Fri, 28 Sep 2007 01:58:05 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JP2001012N12X00@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM); Thu, 27 Sep 2007 19:58:05 -0600 (MDT) Received: from [129.150.49.7] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JP200MKF2SS3190@mail-amer.sun.com>; Thu, 27 Sep 2007 19:58:05 -0600 (MDT) Date: Thu, 27 Sep 2007 20:57:00 -0500 From: Tom Haynes Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18172.7870.360336.68521@gargle.gargle.HOWL> Sender: Thomas.Haynes@Sun.COM To: James Carlson Cc: Rich.Brown@Sun.COM, PSARC-ext@Sun.COM, nfs-mars-iteam@Sun.COM Message-id: <46FC5F6C.2030601@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2898 James Carlson wrote: > Rich.Brown@Sun.COM writes: > >> The code snippet would now look like this: >> >> struct stat statPre; >> struct stat statFile; >> DIR *pdir; >> >> stat(szPath, &statPre); >> pdir = opendir(szPath); >> >> if (S_ISTRIGGER(statPre.st_mode)) { >> stat(szPath, &statPre); >> } >> >> fstat(pdir->dd_fd, &statFile); >> >> if (statPre.st_ino != statFile.st_ino || >> statPre.st_dev != statFile.st_dev) { >> return(EAGAIN); >> } >> > > If doing the stat() call after opendir() works correctly for trigger > points, why would it not work for all other object types? > > I don't quite see what the stat-after-opendir tells you that the > fstat() does not. > > James, The intent of the stat-after-opendir is to refresh the statPre buffer with the inode and device that were loaded as a result of the opendir() causing a trigger mount to fire. For all other object types, the stat-before-opendir will match the stat-after-opendir. For trigger mounts, they will not. I'd also suggest that perhaps my code snippet abstracts the problem too much. If you look at the webrev, http://anthrax.central/net/boora/brmnas/th199096/merger/webrev/, then you can see the context inside *nftw.c. BTW: The webrev has a different symbol for the bits, it used *S_ISTRMP() instead of S_ISTRIGGER(). Thanks, Tom PS: If we look at a test run (with code much like the snippet): # # Do a normal mount # [th199096@burr ~]> sudo mount integrable:/ /mnt # # We see that stat information matches # fprintf(stdout, "Stat flags: (%x, %x, %x)\n", statPre.st_mode, statPre.st_mode & S_IFMT, statPre.st_mode & 0xF0000); # [th199096@burr ~]> a.out /mnt (st_mode, st_ino, st_dev, st_fstype) Pre stat: (41ed, 2, 78643209, nfs) File stat: (41ed, 2, 78643209, nfs) Stat flags: (41ed, 4000, 0) # # And all we have mounted is what we explicitly asked for # [th199096@burr ~]> df -h -F nfs | grep mnt integrable:/ 14G 4.6G 8.9G 35% /mnt # # Now we try the program and cause a mirror mount to occur # [th199096@burr ~]> a.out /mnt/tank (st_mode, st_ino, st_dev, st_fstype) Pre stat: (241ed, 308804, 78643209, nfs) File stat: (41ed, 3, 78643210, nfs) Stat flags: (241ed, 4000, 20000) # # Note that the st_ino and st_dev do not match. This would # trigger a false positive. We need to refresh. # # # We can see the mirror mount took place # [th199096@burr ~]> df -h -F nfs | grep mnt integrable:/ 14G 4.6G 8.9G 35% /mnt integrable:/tank 49G 19K 49G 1% /mnt/tank # # And now, until the mirror mount times out, the statPre and statFile # will match. I.e., the trigger mount is hidden # [th199096@burr ~]> a.out /mnt/tank (st_mode, st_ino, st_dev, st_fstype) Pre stat: (41ed, 3, 78643210, nfs) File stat: (41ed, 3, 78643210, nfs) Stat flags: (41ed, 4000, 0) From Thomas.Haynes@Sun.COM Thu Sep 27 19:55:39 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8S2tdQs028226 for ; Thu, 27 Sep 2007 19:55:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8S2qYu7019643; Thu, 27 Sep 2007 19:52:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JP2004075BKQ800@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Sep 2007 19:52:32 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JP200KBL5BJA830@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Sep 2007 19:52:32 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8S2qVUH018303; Fri, 28 Sep 2007 02:52:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JP200G0155YTW00@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM); Thu, 27 Sep 2007 20:52:31 -0600 (MDT) Received: from [192.168.2.4] ([72.198.16.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JP200EH35BJG510@mail-amer.sun.com>; Thu, 27 Sep 2007 20:52:31 -0600 (MDT) Date: Thu, 27 Sep 2007 21:51:11 -0500 From: Tom Haynes Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <46FC5F6C.2030601@sun.com> Sender: Thomas.Haynes@Sun.COM Cc: James Carlson , Rich.Brown@Sun.COM, PSARC-ext@Sun.COM, nfs-mars-iteam@Sun.COM Message-id: <46FC6C1F.2050609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> <46FC5F6C.2030601@sun.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 380 Tom Haynes wrote: > > I'd also suggest that perhaps my code snippet abstracts the problem > too much. > If you look at the webrev, http://cr.opensolaris.org/~tdh/walk/ > then you can see the context inside *nftw.c. BTW: The webrev has a > different symbol > for the bits, it used *S_ISTRMP() instead of S_ISTRIGGER(). > Still getting used to ARC cases being on OpenSolaris. From Rich.Brown@sun.com Wed Oct 3 10:27:34 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l93HRXUY002637 for ; Wed, 3 Oct 2007 10:27:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l93HOCFW028980; Thu, 4 Oct 2007 01:24:22 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPC00B0BJ0K8400@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 11:24:20 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPC001C3J0JB780@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 11:24:19 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l93HOJ9r009211; Wed, 03 Oct 2007 17:24:19 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPC00701GM66X00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Wed, 03 Oct 2007 11:24:19 -0600 (MDT) Received: from [129.147.9.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPC00N1QJ052450@mail-amer.sun.com>; Wed, 03 Oct 2007 11:24:06 -0600 (MDT) Date: Wed, 03 Oct 2007 12:24:05 -0500 From: Rich Brown Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> Sender: Rich.Brown@sun.com To: PSARC-EXT@sun.com Cc: Thomas.Haynes@sun.com, nfs-mars-iteam@sun.com, Rich.Brown@sun.com Message-id: <4703D035.2090601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 112 At the PSARC meeting today the timer was extended to Wednesday, 10/10/2007. I've updated the IAM file. Rich From carlsonj@phorcys.east.sun.com Wed Oct 3 12:53:14 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l93JrD7C008789 for ; Wed, 3 Oct 2007 12:53:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l93JnxAJ006906; Wed, 3 Oct 2007 20:49:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPC0010TPR8ZS00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 03 Oct 2007 12:49:56 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPC0066OPR5WHA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 03 Oct 2007 12:49:54 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l93JnhHr004141; Wed, 03 Oct 2007 15:49:43 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l93Jnhif004138; Wed, 03 Oct 2007 15:49:43 -0400 (EDT) Date: Wed, 03 Oct 2007 15:49:43 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <46FC5F6C.2030601@sun.com> To: Tom Haynes Cc: Rich.Brown@Sun.COM, PSARC-ext@Sun.COM, nfs-mars-iteam@Sun.COM Message-id: <18179.62039.423658.541140@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> <46FC5F6C.2030601@sun.com> Status: RO Content-Length: 2513 Tom Haynes writes: > James Carlson wrote: > > Rich.Brown@Sun.COM writes: [...] > >> stat(szPath, &statPre); > >> pdir = opendir(szPath); > >> > >> if (S_ISTRIGGER(statPre.st_mode)) { > >> stat(szPath, &statPre); > >> } > >> > >> fstat(pdir->dd_fd, &statFile); > >> > >> if (statPre.st_ino != statFile.st_ino || > >> statPre.st_dev != statFile.st_dev) { > >> return(EAGAIN); > >> } > >> > > > > If doing the stat() call after opendir() works correctly for trigger > > points, why would it not work for all other object types? > > > > I don't quite see what the stat-after-opendir tells you that the > > fstat() does not. [...] > The intent of the stat-after-opendir is to refresh the statPre buffer > with the > inode and device that were loaded as a result of the opendir() causing a > trigger mount to fire. Yes, I see that part. > For all other object types, the stat-before-opendir will match the > stat-after-opendir. > For trigger mounts, they will not. Yep; understood. My question was about how this results in a "security check" and how three calls to stat() (or, rather, one stat() call and two fstat() calls) would achieve some sort of security. Now that I've looked at the code, I think I understand what's really going on, so let me try to recast it and see if this matches your intended results: For all entries, do the stat() first, because the stat() results are what we normally pass along to the user. For directories, open the node. Check, for security reasons, whether fstat() after opening the directory matches the stat() results before opening. However, if that first stat() call reveals that it's a trigger point, then don't bother doing any security test at all. We know it'll change to something new on opendir(), and that's just how it is. The part that tripped me up here was the double stat(). The actual code seems to use a "stat-opendir-fstat-fstat" pattern, where that first fstat is the "new" one, and is actually there just to dummy out the results from the second one. (As a code review comment, it looks like this dummying-out could be done by way of a boolean_t rather than calling fstat() an extra time merely to overwrite &statb.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Thomas.Haynes@Sun.COM Wed Oct 3 13:10:44 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l93KAhOW009387 for ; Wed, 3 Oct 2007 13:10:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l93K7V2X006127; Thu, 4 Oct 2007 04:07:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPC0010LQKJ7X00@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Oct 2007 13:07:31 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPC000NGQKIQI10@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Oct 2007 13:07:30 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l93K7TQh004786; Wed, 03 Oct 2007 20:07:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPC00K01P42P400@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM); Wed, 03 Oct 2007 14:07:29 -0600 (MDT) Received: from [192.168.2.4] ([72.198.16.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPC00I8NQK7W1C0@mail-amer.sun.com>; Wed, 03 Oct 2007 14:07:19 -0600 (MDT) Date: Wed, 03 Oct 2007 15:05:49 -0500 From: Tom Haynes Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18179.62039.423658.541140@gargle.gargle.HOWL> Sender: Thomas.Haynes@Sun.COM To: James Carlson Cc: Rich.Brown@Sun.COM, PSARC-ext@Sun.COM, nfs-mars-iteam@Sun.COM Message-id: <4703F61D.70809@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> <46FC5F6C.2030601@sun.com> <18179.62039.423658.541140@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 751 James Carlson wrote: > > The part that tripped me up here was the double stat(). The actual > code seems to use a "stat-opendir-fstat-fstat" pattern, where that > first fstat is the "new" one, and is actually there just to dummy out > the results from the second one. (As a code review comment, it looks > like this dummying-out could be done by way of a boolean_t rather than > calling fstat() an extra time merely to overwrite &statb.) > > Hmm, with the fstat() as show in the code, I'd agree. But what I'm proposing is to redo the stat() and still do the security check. What if the directory had been moved? With autofs, this is very unlikely. With nfs, it can happen. My intent is to provide a mechanism to detect such edge conditions. From carlsonj@phorcys.east.sun.com Wed Oct 3 13:24:35 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l93KOZA7009823 for ; Wed, 3 Oct 2007 13:24:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l93KLNZa024061; Wed, 3 Oct 2007 13:21:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPC00507R7MFL00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 03 Oct 2007 13:21:22 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPC006A9R7LWAB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 03 Oct 2007 13:21:22 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l93KLBVa004415; Wed, 03 Oct 2007 16:21:11 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l93KLBbd004412; Wed, 03 Oct 2007 16:21:11 -0400 (EDT) Date: Wed, 03 Oct 2007 16:21:11 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <4703F61D.70809@sun.com> To: Tom Haynes Cc: Rich.Brown@sun.com, nfs-mars-iteam@sun.com, PSARC-ext@sun.com Message-id: <18179.63927.586176.908941@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> <46FC5F6C.2030601@sun.com> <18179.62039.423658.541140@gargle.gargle.HOWL> <4703F61D.70809@sun.com> Status: RO Content-Length: 1548 Tom Haynes writes: > James Carlson wrote: > > > > The part that tripped me up here was the double stat(). The actual > > code seems to use a "stat-opendir-fstat-fstat" pattern, where that > > first fstat is the "new" one, and is actually there just to dummy out > > the results from the second one. (As a code review comment, it looks > > like this dummying-out could be done by way of a boolean_t rather than > > calling fstat() an extra time merely to overwrite &statb.) > > > > > > Hmm, with the fstat() as show in the code, I'd agree. OK, then at least we're in sync there. > But what I'm proposing is to redo the stat() and still do the security > check. What if the directory > had been moved? With autofs, this is very unlikely. With nfs, it can > happen. My intent is to > provide a mechanism to detect such edge conditions. In that case, I don't follow. What security problem can you detect by doing a stat() call _after_ having opened a file system node of any sort? Can you provide the details of a scenario in which some sort of timing-based attack is caught by this fix? Perhaps we're getting a bit too close to the point of design or code review instead of architecture, but other than simply disabling the security check, I don't see how the new feature contributes towards additional security. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sommerfeld@sun.com Wed Oct 3 14:22:57 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l93LMvPN011477 for ; Wed, 3 Oct 2007 14:22:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l93LJke7009065; Wed, 3 Oct 2007 14:19:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPC00403TWY2800@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 15:19:46 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPC003NYTWXHQ00@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 15:19:45 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l93LJioc038735; Wed, 03 Oct 2007 17:19:44 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l93LJeLs028981; Wed, 03 Oct 2007 17:19:40 -0400 (EDT) Date: Wed, 03 Oct 2007 17:19:39 -0400 From: Bill Sommerfeld Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18179.63927.586176.908941@gargle.gargle.HOWL> To: James Carlson Cc: Tom Haynes , Rich.Brown@sun.com, nfs-mars-iteam@sun.com, PSARC-ext@sun.com Message-id: <1191446379.27431.66.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> <46FC5F6C.2030601@sun.com> <18179.62039.423658.541140@gargle.gargle.HOWL> <4703F61D.70809@sun.com> <18179.63927.586176.908941@gargle.gargle.HOWL> Status: RO Content-Length: 571 On Wed, 2007-10-03 at 16:21 -0400, James Carlson wrote: > Perhaps we're getting a bit too close to the point of design or code > review instead of architecture, but other than simply disabling the > security check, I don't see how the new feature contributes towards > additional security. There is architecture here. When an interface is added for security reasons, it is essential to have a crisp definition of the threat it addresses in order to allow people to evaluate whether the interface actually addresses the threat. I don't see that here. - Bill From Thomas.Haynes@sun.com Wed Oct 3 15:16:48 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l93MGlKk013091 for ; Wed, 3 Oct 2007 15:16:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l93MD9eD023610; Thu, 4 Oct 2007 06:13:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPC00705WEMRW00@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 16:13:34 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPC0030TWELHR40@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 16:13:33 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l93MDXpJ021337; Wed, 03 Oct 2007 22:13:33 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPC00801WAWCB00@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM); Wed, 03 Oct 2007 16:13:33 -0600 (MDT) Received: from [192.168.2.4] ([72.198.16.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPC00J3QWEKKB50@mail-amer.sun.com>; Wed, 03 Oct 2007 16:13:33 -0600 (MDT) Date: Wed, 03 Oct 2007 17:12:02 -0500 From: Tom Haynes Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <1191446379.27431.66.camel@thunk> Sender: Thomas.Haynes@sun.com To: Bill Sommerfeld Cc: James Carlson , Rich.Brown@sun.com, nfs-mars-iteam@sun.com, PSARC-ext@sun.com Message-id: <470413B2.8080404@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> <46FC5F6C.2030601@sun.com> <18179.62039.423658.541140@gargle.gargle.HOWL> <4703F61D.70809@sun.com> <18179.63927.586176.908941@gargle.gargle.HOWL> <1191446379.27431.66.camel@thunk> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 2320 Bill Sommerfeld wrote: > On Wed, 2007-10-03 at 16:21 -0400, James Carlson wrote: > >> Perhaps we're getting a bit too close to the point of design or code >> review instead of architecture, but other than simply disabling the >> security check, I don't see how the new feature contributes towards >> additional security. >> > > I'd argue that the change that went in for autofs was not correct and removed security. What I want to do is level the playing field here. When a trigger mount occurs, we expect that the stat() and fstat() results will be different. We have the choice of accepting that or redoing the stat() to see if anything else has changed. > There is architecture here. > > When an interface is added for security reasons, it is essential to have > a crisp definition of the threat it addresses in order to allow people > to evaluate whether the interface actually addresses the threat. > > I don't see that here. > > - Bill > > Is this an artifact of the existing code inside walk() or from the new feature? I.e., I can't find a crisp definition of what threats the original code dealt with - I've heard that it handles symlinks and when a subtree is moved. The new feature does not address a threat - the code in walk() does. What the new feature does is allow an exception to that threat. It deterministically lets us know that we are about to encounter an exception. The intent of the original code is that what points to a file is the same as where the file thinks it is located. When the exception was made for autofs, an assumption was made that directory entries inside autofs were carved in stone and safe. What I am arguing, and I'm the first to admit it is hand waving, is that we should not blindly accept that even after we detect the exception will occur, that this directory entry gets a free pass. I think we are talking implementation here - how we handle the exception once we detect it. We know prior customer expectation is that we allow applications which call nftw() to proceed as if a problem had not just occurred. As far as the implementation goes, I don't have a stake in the ground as to whether we record the fact in a boolean or refresh the stat buffer. I'm perfectly willing to ask James to be a code reviewer for the final fix. From sommerfeld@sun.com Wed Oct 3 15:54:42 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l93MsgD2014059 for ; Wed, 3 Oct 2007 15:54:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l93MpUmY020767; Wed, 3 Oct 2007 15:51:31 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPC00A0FY5UJQ00@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 16:51:30 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPC003G8Y5THT50@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 16:51:29 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l93MpSj4062577; Wed, 03 Oct 2007 18:51:28 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l93MpRcN029637; Wed, 03 Oct 2007 18:51:27 -0400 (EDT) Date: Wed, 03 Oct 2007 18:51:27 -0400 From: Bill Sommerfeld Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <470413B2.8080404@sun.com> To: Tom Haynes Cc: James Carlson , Rich.Brown@sun.com, nfs-mars-iteam@sun.com, PSARC-ext@sun.com Message-id: <1191451887.27431.88.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> <46FC5F6C.2030601@sun.com> <18179.62039.423658.541140@gargle.gargle.HOWL> <4703F61D.70809@sun.com> <18179.63927.586176.908941@gargle.gargle.HOWL> <1191446379.27431.66.camel@thunk> <470413B2.8080404@sun.com> Status: RO Content-Length: 611 On Wed, 2007-10-03 at 17:12 -0500, Tom Haynes wrote: > Is this an artifact of the existing code inside walk() or from the new > feature? Both. > I.e., I can't find a crisp definition of what threats the original > code dealt with - I've heard that it handles symlinks and when a > subtree is moved. It's premature to change the existing code until you can explain both the problem it's trying to solve and the way it's getting it wrong. We can do better than rumor and superstition. I suggest looking at the change history of the source file and reading all the CR's for past changes. - Bill From dwc@spartan.eng.sun.com Wed Oct 3 18:02:15 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9412F98016596 for ; Wed, 3 Oct 2007 18:02:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l940w5nv026748; Wed, 3 Oct 2007 18:58:06 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPD00J0H42FI300@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 18:59:03 -0600 (MDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPD003DV42EHNB0@brm-avmta-1.central.sun.com>; Wed, 03 Oct 2007 18:59:02 -0600 (MDT) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l940x2si018182; Wed, 03 Oct 2007 17:59:02 -0700 (PDT) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l940x2M8018181; Wed, 03 Oct 2007 17:59:02 -0700 (PDT) Date: Wed, 03 Oct 2007 17:59:02 -0700 (PDT) From: Don Cragun Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] To: Thomas.Haynes@sun.com Cc: PSARC-ext@sun.com, nfs-mars-iteam@sun.com Message-id: <200710040059.l940x2M8018181@spartan.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1690 Bill, PSARC approved a case a while back that changed "expected or normal or correct" operation for "faster" operation. Because implementing that change broke "expected" behavior, find and other utilities started reporting possible false positives saying that a directory changed between a *stat*() operation and a following opendir(). A bunch of changes have been made trying to stop reporting false positives without making the security hole worse. This case tries to allow applications to determine that they have just stat()ed a file that may generate a false positive. It does do that. But there is still no way to determine whether the directory opened by the opendir() was the requested directory or a spoofed directory planted into the file hierarchy between the original *stat*() call and the opendir() call. Since it leaves the security hole unplugged, I don't see that it buys us anything while it any application trying to use this feature unportable. - Don >Date: Wed, 03 Oct 2007 18:51:27 -0400 >From: Bill Sommerfeld > >On Wed, 2007-10-03 at 17:12 -0500, Tom Haynes wrote: >> Is this an artifact of the existing code inside walk() or from the new >> feature? > >Both. > >> I.e., I can't find a crisp definition of what threats the original >> code dealt with - I've heard that it handles symlinks and when a >> subtree is moved. > >It's premature to change the existing code until you can explain both >the problem it's trying to solve and the way it's getting it wrong. > >We can do better than rumor and superstition. > >I suggest looking at the change history of the source file and reading >all the CR's for past changes. > > - Bill From carlsonj@phorcys.east.sun.com Thu Oct 4 05:48:14 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l94CmEPg001488 for ; Thu, 4 Oct 2007 05:48:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l94Ci3MW002039; Thu, 4 Oct 2007 06:44:04 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPE00L0B0R0LK00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Oct 2007 05:45:00 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPE00KOB0QYCE00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Oct 2007 05:44:59 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l94CilWq021817; Thu, 04 Oct 2007 08:44:47 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l94Cilbw021814; Thu, 04 Oct 2007 08:44:47 -0400 (EDT) Date: Thu, 04 Oct 2007 08:44:47 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <200710040059.l940x2M8018181@spartan.SFBay.Sun.COM> To: Don Cragun Cc: Thomas.Haynes@sun.com, PSARC-ext@sun.com, nfs-mars-iteam@sun.com Message-id: <18180.57407.373594.506951@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710040059.l940x2M8018181@spartan.SFBay.Sun.COM> Status: RO Content-Length: 2506 Don Cragun writes: > This case tries to allow applications to determine that they > have just stat()ed a file that may generate a false positive. It does > do that. But there is still no way to determine whether the directory > opened by the opendir() was the requested directory or a spoofed > directory planted into the file hierarchy between the original *stat*() > call and the opendir() call. Yes, that's exactly the point I was raising. The problem is that doing two stats after opendir() doesn't really add any security, as it doesn't cover for a race condition that anyone has been able to describe, so I think we ought to be direct and say that we are deliberately disabling this security check in this one case. The code presented showed two fstat() calls on the same file descriptor, and a compare of the results. If those don't show the same node, then I think the machine should be panicked. ;-} Even if the code were changed to do stat() first (after the opendir() that causes the trigger) and then an fstat(), it's not clear what we're protecting against. I don't see the threat model. We're going to do an fchdir() to the file descriptor returned by opendir(), so who cares whether the identity of the object named by the original path has been changed in the meantime? Couldn't it change at _any_ point between the new stat() call and the fchdir()? If so, such a change would be undetected, and thus we're not gaining any security. > Since it leaves the security hole > unplugged, I don't see that it buys us anything while it any > application trying to use this feature unportable. Assuming that other OSes present the same problem -- mere stat() doesn't trigger a fetch of the correct information, but opendir() does -- it'd be nice to see a standards-based solution for this. I'm not sure that's a requirement here, though. I think the alternative (one that preserves the existing security checks) would be to add a new flag to fstatat(2). Create a new flag called (say) AT_TRIGGER, and have it invoke the same autofs triggering that opendir() does, so that the node information returned is correct. That way, you wouldn't have to do the double stat after opendir return, or disable the test. I have no idea how hard that might be, though. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Joerg.Schilling@fokus.fraunhofer.de Thu Oct 4 07:41:52 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l94EfqCh003246 for ; Thu, 4 Oct 2007 07:41:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l94EcaRe013784; Thu, 4 Oct 2007 15:38:37 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPE0080F60C6E00@brm-avmta-1.central.sun.com>; Thu, 04 Oct 2007 08:38:36 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPE006MN609YJ10@brm-avmta-1.central.sun.com>; Thu, 04 Oct 2007 08:38:34 -0600 (MDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l94Eb2l9013037; Thu, 04 Oct 2007 14:38:33 +0000 (GMT) Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay23i.sun.com with ESMTP id BT-MMP-753498; Thu, 04 Oct 2007 14:38:33 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms25es.sun.com with ESMTP id BT-MMP-1625650; Thu, 04 Oct 2007 14:38:33 +0000 (Z) Received: from mailgw11.fraunhofer.de ([153.96.1.23] [153.96.1.23]) by relay24i.sun.com with ESMTP id BT-MMP-15921935; Thu, 04 Oct 2007 14:38:32 +0000 (Z) Received: from mailgw11.fraunhofer.de (localhost [127.0.0.1]) by mailgw11.fraunhofer.de (8.13.5+/8.13.4) with ESMTP id l94EcVGe005766; Thu, 04 Oct 2007 16:38:31 +0200 (MEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw11.fraunhofer.de (8.13.5+/8.13.4) with ESMTP id l94EcRwP005651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 04 Oct 2007 16:38:29 +0200 (MEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id l94EcORv021058; Thu, 04 Oct 2007 16:38:24 +0200 (MEST) Received: from burner ([10.147.65.166]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 04 Oct 2007 16:38:25 +0200 Date: Thu, 04 Oct 2007 16:34:33 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18180.57407.373594.506951@gargle.gargle.HOWL> To: james.d.carlson@sun.com, don.cragun@sun.com Cc: Thomas.Haynes@sun.com, PSARC-ext@sun.com, nfs-mars-iteam@sun.com Message-id: <4704f9f9.MljRj15omNhXha3w%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 X-Fraunhofer-Email-Policy: accepted References: <200710040059.l940x2M8018181@spartan.SFBay.Sun.COM> <18180.57407.373594.506951@gargle.gargle.HOWL> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 04 Oct 2007 14:38:25.0011 (UTC) FILETIME=[38557430:01C80694] Status: RO Content-Length: 1299 James Carlson wrote: > Assuming that other OSes present the same problem -- mere stat() > doesn't trigger a fetch of the correct information, but opendir() does > -- it'd be nice to see a standards-based solution for this. I'm not > sure that's a requirement here, though. > > I think the alternative (one that preserves the existing security > checks) would be to add a new flag to fstatat(2). Create a new flag > called (say) AT_TRIGGER, and have it invoke the same autofs triggering > that opendir() does, so that the node information returned is > correct. That way, you wouldn't have to do the double stat after > opendir return, or disable the test. First: I don't like a flag that lives inside st_mode as it could be in conflict with future POSIX enhancements. The idea that: f = open(".", 0); fstatat(f, "dir", &stbuf, AT_TRIGGER); returns the same struct stat as: dp = opendir("dir"); stat("dir", &stbuf); looks much more aligned to the spirit of POSIX. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Thomas.Haynes@sun.com Thu Oct 4 21:04:17 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9544H6m019114 for ; Thu, 4 Oct 2007 21:04:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95407dv014130 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Oct 2007 22:00:09 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPF00I2175UJN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Oct 2007 22:01:06 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPF00I6C75SGU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Oct 2007 22:01:04 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l95414pR019782 for ; Fri, 05 Oct 2007 04:01:04 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPF00401731G700@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Oct 2007 22:01:04 -0600 (MDT) Received: from [192.168.2.115] ([72.198.16.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPF008TU75RTHB0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Oct 2007 22:01:04 -0600 (MDT) Date: Thu, 04 Oct 2007 22:59:30 -0500 From: Tom Haynes Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <1191451887.27431.88.camel@thunk> Sender: Thomas.Haynes@sun.com To: Rich Brown Cc: PSARC-ext@sun.com Message-id: <4705B6A2.10201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709272115.l8RLFE3x023005@sac.sfbay.sun.com> <18172.7870.360336.68521@gargle.gargle.HOWL> <46FC5F6C.2030601@sun.com> <18179.62039.423658.541140@gargle.gargle.HOWL> <4703F61D.70809@sun.com> <18179.63927.586176.908941@gargle.gargle.HOWL> <1191446379.27431.66.camel@thunk> <470413B2.8080404@sun.com> <1191451887.27431.88.camel@thunk> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1358 Bill Sommerfeld wrote: > > It's premature to change the existing code until you can explain both > the problem it's trying to solve and the way it's getting it wrong. > > > Clarifying a few points... This proposal does not add security. This case proposes a file system independent interface which will replace an existing file system specific check within nftw(3C). There are a few subtle cases that nftw(3C) needs to deal with between the time it stat()s a directory and the time it enters that directory. These are security-related in that the operations could be malicious or inadvertent. In either case, the current implementation of nftw(3C) handles them. CR 5032820 [1] describes the original security concerns with symlinks. CR 6198351 [2] describes how the automounter could produce a false-positive for a security breach inside nftw(3C) The solution implemented by CR 6198351 compared the fstype with the string "autofs". This case proposes to replace that check with a file system independent check by adding S_IFTRIGGER to st_mode and a corresponding test macro, IS_IFTRIGGER(). This will enable mirror-mounts (PSARC 2007/416) and future NFS-related enhancements to work correctly. [1] 5032820 nftw must make sure it isn't tricked into following symlinks [2] 6198351 automounting causes EAGAIN for nftw(), hence find(1) can fail From Thomas.Haynes@Sun.COM Thu Oct 4 21:22:01 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l954M1Cm019237 for ; Thu, 4 Oct 2007 21:22:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l954HU7K020270; Thu, 4 Oct 2007 21:17:30 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPF005017X6CG00@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Oct 2007 21:17:30 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPF0039K7X5OQ40@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Oct 2007 21:17:29 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l954HTjQ005385; Fri, 05 Oct 2007 04:17:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPF00F017UE9P00@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM); Thu, 04 Oct 2007 22:17:29 -0600 (MDT) Received: from [192.168.2.115] ([72.198.16.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPF00KHF7X3XJC0@mail-amer.sun.com>; Thu, 04 Oct 2007 22:17:28 -0600 (MDT) Date: Thu, 04 Oct 2007 23:15:55 -0500 From: Tom Haynes Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18180.57407.373594.506951@gargle.gargle.HOWL> Sender: Thomas.Haynes@Sun.COM To: James Carlson Cc: Don Cragun , PSARC-ext@Sun.COM Message-id: <4705BA7B.5010001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710040059.l940x2M8018181@spartan.SFBay.Sun.COM> <18180.57407.373594.506951@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1390 James Carlson wrote: > Don Cragun writes: > >> This case tries to allow applications to determine that they >> have just stat()ed a file that may generate a false positive. It does >> do that. But there is still no way to determine whether the directory >> opened by the opendir() was the requested directory or a spoofed >> directory planted into the file hierarchy between the original *stat*() >> call and the opendir() call. >> > > Yes, that's exactly the point I was raising. > I think we are all in agreement with that statement and are expressing our concerns in different manners. > The problem is that doing two stats after opendir() doesn't really add > any security, as it doesn't cover for a race condition that anyone has > been able to describe, so I think we ought to be direct and say that > we are deliberately disabling this security check in this one case. > Agreed, I can't express the race condition that I believed was still there. I also agree with the statement that we need to be direct here. > I think the alternative (one that preserves the existing security > checks) would be to add a new flag to fstatat(2). > That approach would trigger a mount before the call to fstatat(2). The key design point in my proposal is that we want to be able to detect that a directory is a trigger mount without actually triggering the mount. From don.cragun@sun.com Fri Oct 5 07:33:59 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95EXwp6028174 for ; Fri, 5 Oct 2007 07:33:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95ETmHT052937; Fri, 5 Oct 2007 08:29:48 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG002030B9E800@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 07:30:45 -0700 (PDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG00JTZ0B9UJD0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 07:30:45 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id l95EUiRO022368; Fri, 05 Oct 2007 07:30:45 -0700 (PDT) Date: Fri, 05 Oct 2007 07:30:45 -0700 (PDT) From: Don Cragun Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] To: James.D.Carlson@sun.com, Thomas.Haynes@sun.com Cc: don.cragun@sun.com, PSARC-ext@sun.com Reply-to: Don Cragun Message-id: <200710051430.l95EUiRO022368@spartan.SFBay.Sun.COM> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: f0CcvHKnigdPSb9cbvNXqw== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2158 >Date: Thu, 04 Oct 2007 23:15:55 -0500 >From: Tom Haynes >James Carlson wrote: >> The problem is that doing two stats after opendir() doesn't really add >> any security, as it doesn't cover for a race condition that anyone has >> been able to describe, so I think we ought to be direct and say that >> we are deliberately disabling this security check in this one case. >> > >Agreed, I can't express the race condition that I believed was still there. > >I also agree with the statement that we need to be direct here. > > >> I think the alternative (one that preserves the existing security >> checks) would be to add a new flag to fstatat(2). >> > >That approach would trigger a mount before the call to fstatat(2). The >key design >point in my proposal is that we want to be able to detect that a >directory is a >trigger mount without actually triggering the mount. Any approach that doesn't force the mount is going to leave a security hole. The security hole while doing an ls -l probably isn't important. I understand that there is a significant performance penalty forcing mounts on all *stat*() calls. But surely we can force the mounts if an application explicitly asks for it in an fstatat() call when it knows that skipping the mount may lead to an otherwise undetectable security hole. Both ftw() and nftw() should ask for it. (Forcing the mount on the fstatat() in ftw() and nftw() will make them run faster; not slower. They will be forcing the mounts anyway and this avoids additional checks that have been added trying to plug the security hole that was created by cases approved earlier.) I strongly suggest that you reconsider Jim's suggestion. I also strongly suggest again, that you run this by IBM, HP, and RedHat to try to get buy-in for us all doing this the same way. If you need contacts, I can supply them. (With current timing constraints, I don't see any way to get a new fstatat() flag into the upcoming revision of POSIX.1-2001 and SUSv3; but if we get buy in from the other OS vendors participating in The Austin Group, we should be able to add it into the next revision.) - Don From Thomas.Haynes@sun.com Fri Oct 5 09:33:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95GXhgO000658 for ; Fri, 5 Oct 2007 09:33:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95GUQRx022790; Fri, 5 Oct 2007 17:30:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG008015URGL00@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Oct 2007 09:30:27 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG002HO5UQJO70@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Oct 2007 09:30:27 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l95GUQMg028714; Fri, 05 Oct 2007 16:30:26 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPG008015CCI400@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM); Fri, 05 Oct 2007 10:30:26 -0600 (MDT) Received: from [192.168.2.115] ([72.198.16.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPG00M435UKK1D0@mail-amer.sun.com>; Fri, 05 Oct 2007 10:30:20 -0600 (MDT) Date: Fri, 05 Oct 2007 11:28:45 -0500 From: Tom Haynes Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <200710051430.l95EUiRO022368@spartan.SFBay.Sun.COM> Sender: Thomas.Haynes@sun.com To: Don Cragun Cc: James.D.Carlson@sun.com, PSARC-ext@sun.com Message-id: <4706663D.8050908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051430.l95EUiRO022368@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1087 Don Cragun wrote: > > Any approach that doesn't force the mount is going to leave a security > hole. The security hole while doing an ls -l probably isn't > important. I understand that there is a significant performance > penalty forcing mounts on all *stat*() calls. But surely we can force > the mounts if an application explicitly asks for it in an fstatat() > call when it knows that skipping the mount may lead to an otherwise > undetectable security hole. Both ftw() and nftw() should ask for it. > (Forcing the mount on the fstatat() in ftw() and nftw() will make them > run faster; not slower. They will be forcing the mounts anyway and > this avoids additional checks that have been added trying to plug the > security hole that was created by cases approved earlier.) > > > - Don > > The issue here is that by the time we get to the fstatat() call, the mount has already occurred. It isn't just the opendir() call which forces the underlying vnops to trigger the mount. Whatever call we make to get our hands on the file descriptor will force the mount to occur. From don.cragun@sun.com Fri Oct 5 10:45:09 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95Hj9Eb003121 for ; Fri, 5 Oct 2007 10:45:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95HfuYd009545; Fri, 5 Oct 2007 10:41:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00K0H95VXM00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 10:41:55 -0700 (PDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG004DT95UC180@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 10:41:54 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id l95HfsZv023685; Fri, 05 Oct 2007 10:41:54 -0700 (PDT) Date: Fri, 05 Oct 2007 10:41:54 -0700 (PDT) From: Don Cragun Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] To: Thomas.Haynes@sun.com Cc: PSARC-ext@sun.com Reply-to: Don Cragun Message-id: <200710051741.l95HfsZv023685@spartan.SFBay.Sun.COM> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: mHsCV73HHjnmhCLxfNxlew== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2029 >Date: Fri, 05 Oct 2007 11:28:45 -0500 >From: Tom Haynes > >Don Cragun wrote: >> >> Any approach that doesn't force the mount is going to leave a security >> hole. The security hole while doing an ls -l probably isn't >> important. I understand that there is a significant performance >> penalty forcing mounts on all *stat*() calls. But surely we can force >> the mounts if an application explicitly asks for it in an fstatat() >> call when it knows that skipping the mount may lead to an otherwise >> undetectable security hole. Both ftw() and nftw() should ask for it. >> (Forcing the mount on the fstatat() in ftw() and nftw() will make them >> run faster; not slower. They will be forcing the mounts anyway and >> this avoids additional checks that have been added trying to plug the >> security hole that was created by cases approved earlier.) >> >> >> - Don > >The issue here is that by the time we get to the fstatat() call, the >mount has already >occurred. It isn't just the opendir() call which forces the underlying >vnops to trigger >the mount. Whatever call we make to get our hands on the file descriptor >will >force the mount to occur. NO! We don't have a file descriptor yet. The synopsis for fstatat() is: int fstatat(int fildes, const char *path, struct stat *buf, int flag); We're not talking about having flag AT_TRIGGER have any effect on fildes; we're talking about AT_TRIGGER forcing any path argument that names a directory for which the current proposal would set the S_IFTRIGGER bit in the mode field to instead force the mount before returning mode bits. (So that after the sequence: fstatat(fildes, dir, &before, AT_TRIGGER); or: fstatat(0, dir, &before, AT_TRIGGER | AT_FDCWD) followed by: dirp = opendir(dir); fstat(dirfd(dirp), &after); the application will know that if: before.st_ino != after.st_ino || before.st_dev != after.st_dev then someone changed dir between the fstatat() and the opendir() calls with no chance for spoofing.) - Don From carlsonj@phorcys.east.sun.com Fri Oct 5 11:50:42 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95IoeqY006115 for ; Fri, 5 Oct 2007 11:50:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l95Il7uY004890; Sat, 6 Oct 2007 02:47:24 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00417C6XY900@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 11:47:21 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG004CXC6TC6C0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 11:47:17 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l95Il5JZ026806; Fri, 05 Oct 2007 14:47:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l95Il5xQ026803; Fri, 05 Oct 2007 14:47:05 -0400 (EDT) Date: Fri, 05 Oct 2007 14:47:05 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <4706663D.8050908@sun.com> To: Tom Haynes Cc: Don Cragun , PSARC-ext@sun.com Message-id: <18182.34473.92278.15681@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051430.l95EUiRO022368@spartan.SFBay.Sun.COM> <4706663D.8050908@sun.com> Status: RO Content-Length: 2011 Tom Haynes writes: > The issue here is that by the time we get to the fstatat() call, the > mount has already > occurred. It isn't just the opendir() call which forces the underlying > vnops to trigger > the mount. Whatever call we make to get our hands on the file descriptor > will > force the mount to occur. The idea was to have the very first status check of the file be fstatat(), using the 'fd' parameter set to AT_FDCWD, and the 'path' presented to fstatat() would be the one you're just about to use for opendir(). Then you can pass in the new AT_TRIGGER (or whatever you want to call it; prepend with "_" if you want to keep it private until the standards organizations can act), and fstatat() can trigger the automount if needed before reading and returning the stat structure. I view this as a security improvement, as it brings the stat-opendir-fstat sequence into line for the special case of autofs/nfs. Your proposal is roughly equivalent to the current code. The current code just does a string compare to see if the node is autofs/nfs, and the fix you've proposed is to add a flag that has exactly equivalent semantics and simply avoids the ugly string compares. Thus, while I see that your flag is indeed an improvement over the current code (it makes the existing test much cleaner), and I'm not opposed to it on those grounds, I just think it could be better. The only question I have is whether AT_TRIGGER is too hard to implement. I can't answer that question, because I don't know this code well. I'd like to know from you (or from any expert on the code in question) whether this is a reasonable possibility. If it's not, then I'm fine with your original change plus an RFE for the stat-with-trigger feature, because I think it's a cleaner way to go. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From don.cragun@sun.com Fri Oct 5 12:06:54 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95J6qcB006727 for ; Fri, 5 Oct 2007 12:06:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l95J3R2P011529; Sat, 6 Oct 2007 03:03:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00A3ACXX6F00@brm-avmta-1.central.sun.com>; Fri, 05 Oct 2007 13:03:33 -0600 (MDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG002XNCXTNE40@brm-avmta-1.central.sun.com>; Fri, 05 Oct 2007 13:03:30 -0600 (MDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id l95J3TWm023783; Fri, 05 Oct 2007 12:03:29 -0700 (PDT) Date: Fri, 05 Oct 2007 12:03:29 -0700 (PDT) From: Don Cragun Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] To: Thomas.Haynes@sun.com Cc: PSARC-ext@sun.com Reply-to: Don Cragun Message-id: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: D1abmH9qoUJor7RCI41lxw== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2554 >From: James Carlson >Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout > >Tom Haynes writes: >> The issue here is that by the time we get to the fstatat() call, the >> mount has already >> occurred. It isn't just the opendir() call which forces the underlying >> vnops to trigger >> the mount. Whatever call we make to get our hands on the file descriptor >> will >> force the mount to occur. > >The idea was to have the very first status check of the file be >fstatat(), using the 'fd' parameter set to AT_FDCWD, and the 'path' >presented to fstatat() would be the one you're just about to use for >opendir(). > >Then you can pass in the new AT_TRIGGER (or whatever you want to call >it; prepend with "_" if you want to keep it private until the >standards organizations can act), and fstatat() can trigger the >automount if needed before reading and returning the stat structure. > >I view this as a security improvement, as it brings the >stat-opendir-fstat sequence into line for the special case of >autofs/nfs. Yes. > >Your proposal is roughly equivalent to the current code. The current >code just does a string compare to see if the node is autofs/nfs, and >the fix you've proposed is to add a flag that has exactly equivalent >semantics and simply avoids the ugly string compares. > >Thus, while I see that your flag is indeed an improvement over the >current code (it makes the existing test much cleaner), and I'm not >opposed to it on those grounds, I just think it could be better. The >only question I have is whether AT_TRIGGER is too hard to implement. >I can't answer that question, because I don't know this code well. >I'd like to know from you (or from any expert on the code in question) >whether this is a reasonable possibility. I'm still strongly opposed. If the path presented to the first *stat*() function is a symlink pointing to an autofs/nfs directory, the symlink can be changed between the *stat*() call and the opendir() call and this spoofing action cannot be reliably detected by the application. With AT_TRIGGER, this spoofing action can be caught every time it happens. - Don > >If it's not, then I'm fine with your original change plus an RFE for >the stat-with-trigger feature, because I think it's a cleaner way to >go. > >-- >James Carlson, Solaris Networking >Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 >MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Fri Oct 5 12:40:27 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95JeQnh007355 for ; Fri, 5 Oct 2007 12:40:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95JbEcI010049; Fri, 5 Oct 2007 12:37:14 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00A01EI28800@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 12:37:14 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG004E2EI1C9B0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 12:37:13 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l95Jb1te027137; Fri, 05 Oct 2007 15:37:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l95Jb1Pc027134; Fri, 05 Oct 2007 15:37:01 -0400 (EDT) Date: Fri, 05 Oct 2007 15:37:01 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> To: Don Cragun Cc: Thomas.Haynes@sun.com, PSARC-ext@sun.com Message-id: <18182.37469.358970.911832@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> Status: RO Content-Length: 1614 Don Cragun writes: > >From: James Carlson > >Thus, while I see that your flag is indeed an improvement over the > >current code (it makes the existing test much cleaner), and I'm not > >opposed to it on those grounds, I just think it could be better. The > >only question I have is whether AT_TRIGGER is too hard to implement. > >I can't answer that question, because I don't know this code well. > >I'd like to know from you (or from any expert on the code in question) > >whether this is a reasonable possibility. > > I'm still strongly opposed. If the path presented to the first > *stat*() function is a symlink pointing to an autofs/nfs directory, the > symlink can be changed between the *stat*() call and the opendir() call > and this spoofing action cannot be reliably detected by the > application. With AT_TRIGGER, this spoofing action can be caught every > time it happens. Yes. However, that's actually the same state we are in right now (with no fix at all), and the state we've been in since February 2005 when CR 6198351 integrated and added the autofs-testing logic. It's a hole that ought to be fixed, but it's a little less clear to me that it's this project team's responsibility to do so. I'm not disagreeing with you. I think you've got an entirely valid position here. I'm just pointing out that these are perhaps separable issues. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@Sun.COM Fri Oct 5 13:01:48 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95K1miE008103 for ; Fri, 5 Oct 2007 13:01:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95JwYrR020085; Fri, 5 Oct 2007 12:58:36 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00D6VFHMO200@brm-avmta-1.central.sun.com>; Fri, 05 Oct 2007 13:58:35 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG002HQFHJMZ70@brm-avmta-1.central.sun.com>; Fri, 05 Oct 2007 13:58:31 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l95JwVXX021745; Fri, 05 Oct 2007 14:58:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l95JwVnE021744; Fri, 05 Oct 2007 14:58:31 -0500 (CDT) Date: Fri, 05 Oct 2007 14:58:31 -0500 From: Nicolas Williams Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18182.37469.358970.911832@gargle.gargle.HOWL> To: James Carlson Cc: Don Cragun , Thomas.Haynes@Sun.COM, PSARC-ext@Sun.COM Message-id: <20071005195830.GU19909@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1080 On Fri, Oct 05, 2007 at 03:37:01PM -0400, James Carlson wrote: > Don Cragun writes: > > I'm still strongly opposed. If the path presented to the first > > *stat*() function is a symlink pointing to an autofs/nfs directory, the > > symlink can be changed between the *stat*() call and the opendir() call > > and this spoofing action cannot be reliably detected by the > > application. With AT_TRIGGER, this spoofing action can be caught every > > time it happens. > > Yes. However, that's actually the same state we are in right now > (with no fix at all), and the state we've been in since February 2005 > when CR 6198351 integrated and added the autofs-testing logic. It's a > hole that ought to be fixed, but it's a little less clear to me that > it's this project team's responsibility to do so. This hole is not much of a hole for the autofs case because users don't normally get to make symlinks in autofs directories. That consideration does not apply here, so technically the change made for autofs did not introduce a security bug, but this change would. Nico -- From carlsonj@phorcys.east.sun.com Fri Oct 5 13:10:49 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95KAmv2008292 for ; Fri, 5 Oct 2007 13:10:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95K7Vvv022368; Fri, 5 Oct 2007 21:07:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00D05FWKL200@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 13:07:33 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG00D4WFWJC300@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 13:07:32 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l95K7Jsv027318; Fri, 05 Oct 2007 16:07:19 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l95K7JHI027315; Fri, 05 Oct 2007 16:07:19 -0400 (EDT) Date: Fri, 05 Oct 2007 16:07:19 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <20071005195830.GU19909@Sun.COM> To: Nicolas Williams Cc: Thomas.Haynes@sun.com, Don Cragun , PSARC-ext@sun.com Message-id: <18182.39287.767227.501357@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> Status: RO Content-Length: 2017 Nicolas Williams writes: > On Fri, Oct 05, 2007 at 03:37:01PM -0400, James Carlson wrote: > > Don Cragun writes: > > > I'm still strongly opposed. If the path presented to the first > > > *stat*() function is a symlink pointing to an autofs/nfs directory, the > > > symlink can be changed between the *stat*() call and the opendir() call > > > and this spoofing action cannot be reliably detected by the > > > application. With AT_TRIGGER, this spoofing action can be caught every > > > time it happens. > > > > Yes. However, that's actually the same state we are in right now > > (with no fix at all), and the state we've been in since February 2005 > > when CR 6198351 integrated and added the autofs-testing logic. It's a > > hole that ought to be fixed, but it's a little less clear to me that > > it's this project team's responsibility to do so. > > This hole is not much of a hole for the autofs case because users don't > normally get to make symlinks in autofs directories. That consideration > does not apply here, so technically the change made for autofs did not > introduce a security bug, but this change would. How's that? The proposed change looks equivalent to me in terms of security. Have you looked at the webrev? Previously, we compared st_fstype from the first stat() against "autofs" to check for trigger points, and now (with the proposed change, and in exactly the same code) we look at st_mode from the first stat() and check for the S_TRIGGER flag. The two versions do exactly the same thing functionally, so I don't see how this change introduces any flaw that isn't there today and hasn't been there for more than 2.5 years. I also agree that users can't normally write to those directories, so it's likely moot -- both before and after this project. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From John.Plocher@sun.com Fri Oct 5 13:26:37 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95KQaVa008442 for ; Fri, 5 Oct 2007 13:26:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95KNFHZ028534; Fri, 5 Oct 2007 21:23:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00F0JGMWAY00@brm-avmta-1.central.sun.com>; Fri, 05 Oct 2007 14:23:20 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG0027PGMTN0A0@brm-avmta-1.central.sun.com>; Fri, 05 Oct 2007 14:23:17 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l95KNGej017495; Fri, 05 Oct 2007 13:23:16 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPG00J01GK5Q700@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Fri, 05 Oct 2007 13:23:16 -0700 (PDT) Received: from wp668.sfbay.sun.com ([129.146.58.87]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPG006B7GMPN6E0@fe-sfbay-10.sun.com>; Fri, 05 Oct 2007 13:23:13 -0700 (PDT) Date: Fri, 05 Oct 2007 13:23:06 -0700 From: John Plocher Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18182.39287.767227.501357@gargle.gargle.HOWL> Sender: John.Plocher@sun.com To: James Carlson Cc: Nicolas Williams , Don Cragun , Thomas.Haynes@sun.com, PSARC-ext@sun.com Message-id: <47069D2A.7030801@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 369 James Carlson wrote: > How's that? The difference I see is that in the original case, only autofs triggered mount points were handled by this code path; in the new code allows anything that sets S_TRIGGER will, uhm, trigger this code path. As long as only autofs does it, things are identical. If anything else does... At least, that's how I parsed it. -John From Nicolas.Williams@sun.com Fri Oct 5 13:35:26 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95KZOuE008618 for ; Fri, 5 Oct 2007 13:35:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l95KW6Jm017494; Sat, 6 Oct 2007 04:32:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00G0JH1J5Y00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 13:32:07 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG00D7UH1HC320@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 13:32:06 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l95KW5jn021774; Fri, 05 Oct 2007 15:32:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l95KW5sh021773; Fri, 05 Oct 2007 15:32:05 -0500 (CDT) Date: Fri, 05 Oct 2007 15:32:05 -0500 From: Nicolas Williams Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18182.39287.767227.501357@gargle.gargle.HOWL> To: James Carlson Cc: Thomas.Haynes@sun.com, Don Cragun , PSARC-ext@sun.com Message-id: <20071005203205.GW19909@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 974 On Fri, Oct 05, 2007 at 04:07:19PM -0400, James Carlson wrote: > Nicolas Williams writes: > > This hole is not much of a hole for the autofs case because users don't > > normally get to make symlinks in autofs directories. That consideration > > does not apply here, so technically the change made for autofs did not > > introduce a security bug, but this change would. > > How's that? > > The proposed change looks equivalent to me in terms of security. Have > you looked at the webrev? Previously, we compared st_fstype from the > first stat() against "autofs" to check for trigger points, and now > (with the proposed change, and in exactly the same code) we look at > st_mode from the first stat() and check for the S_TRIGGER flag. The > two versions do exactly the same thing functionally, so I don't see > how this change introduces any flaw that isn't there today and hasn't > been there for more than 2.5 years. Oh, I see, I forgot about the S_TRIGGER flag. From carlsonj@phorcys.east.sun.com Fri Oct 5 13:40:19 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95KeJkA008700 for ; Fri, 5 Oct 2007 13:40:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95Kb58s001406; Fri, 5 Oct 2007 13:37:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00G27H9T5M00@brm-avmta-1.central.sun.com>; Fri, 05 Oct 2007 14:37:05 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG002B4H9SNB80@brm-avmta-1.central.sun.com>; Fri, 05 Oct 2007 14:37:04 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l95Kaqp1027525; Fri, 05 Oct 2007 16:36:52 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l95Kaqlw027522; Fri, 05 Oct 2007 16:36:52 -0400 (EDT) Date: Fri, 05 Oct 2007 16:36:52 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <47069D2A.7030801@Sun.Com> To: John Plocher Cc: Thomas.Haynes@sun.com, Don Cragun , PSARC-ext@sun.com Message-id: <18182.41060.44902.834525@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> <47069D2A.7030801@Sun.Com> Status: RO Content-Length: 873 John Plocher writes: > James Carlson wrote: > > How's that? > > The difference I see is that in the original case, only autofs > triggered mount points were handled by this code path; in the > new code allows anything that sets S_TRIGGER will, uhm, trigger > this code path. > > As long as only autofs does it, things are identical. If anything > else does... > > At least, that's how I parsed it. That's what appears to me to make it identical. If the project team is actually making _more_ file systems set S_TRIGGER, then I agree that the bug has been crowbared open a bit, and that might well be enough to push me into the "opposed" camp. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Fri Oct 5 13:43:41 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95KhfUs008762 for ; Fri, 5 Oct 2007 13:43:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95KeTCk028675; Fri, 5 Oct 2007 13:40:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00N01HFG4900@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Oct 2007 13:40:28 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG00GIUHFG9GA0@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Oct 2007 13:40:28 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l95KeO8c021785; Fri, 05 Oct 2007 15:40:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l95KeO7D021784; Fri, 05 Oct 2007 15:40:24 -0500 (CDT) Date: Fri, 05 Oct 2007 15:40:24 -0500 From: Nicolas Williams Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18182.41060.44902.834525@gargle.gargle.HOWL> To: James Carlson Cc: John Plocher , Thomas.Haynes@sun.com, Don Cragun , PSARC-ext@sun.com Message-id: <20071005204024.GX19909@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> <47069D2A.7030801@Sun.Com> <18182.41060.44902.834525@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 386 On Fri, Oct 05, 2007 at 04:36:52PM -0400, James Carlson wrote: > If the project team is actually making _more_ file systems set > S_TRIGGER, then I agree that the bug has been crowbared open a bit, > and that might well be enough to push me into the "opposed" camp. Isn't that what's intended here? that the trigger flag will be used on NFSv4 paths that when crossed trigger a mount? From Rich.Brown@sun.com Fri Oct 5 13:49:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95Knhw3008829 for ; Fri, 5 Oct 2007 13:49:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95Kk86x008398; Fri, 5 Oct 2007 21:46:30 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00007HPHCB00@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Oct 2007 13:46:29 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG00G5KHPH9GB0@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Oct 2007 13:46:29 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l95KkTDP026066; Fri, 05 Oct 2007 20:46:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPG00I01HH05C00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Fri, 05 Oct 2007 14:46:29 -0600 (MDT) Received: from [129.147.9.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPG000R7HPGRL00@mail-amer.sun.com>; Fri, 05 Oct 2007 14:46:28 -0600 (MDT) Date: Fri, 05 Oct 2007 15:46:28 -0500 From: Rich Brown Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18182.41060.44902.834525@gargle.gargle.HOWL> Sender: Rich.Brown@sun.com To: James Carlson Cc: John Plocher , Thomas.Haynes@sun.com, Don Cragun , PSARC-ext@sun.com Message-id: <4706A2A4.7070002@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> <47069D2A.7030801@Sun.Com> <18182.41060.44902.834525@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 856 James Carlson wrote: > John Plocher writes: >> James Carlson wrote: >>> How's that? >> The difference I see is that in the original case, only autofs >> triggered mount points were handled by this code path; in the >> new code allows anything that sets S_TRIGGER will, uhm, trigger >> this code path. >> >> As long as only autofs does it, things are identical. If anything >> else does... >> >> At least, that's how I parsed it. > > That's what appears to me to make it identical. > > If the project team is actually making _more_ file systems set > S_TRIGGER, then I agree that the bug has been crowbared open a bit, > and that might well be enough to push me into the "opposed" camp. > The team just met with Don Cragun to discuss the concerns. We've all agreed on how to proceed. Notes coming out shortly and I'll summarize on the alias. Rich From carlsonj@phorcys.east.sun.com Fri Oct 5 13:50:54 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95Kor2o008848 for ; Fri, 5 Oct 2007 13:50:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95KlZQY008787; Fri, 5 Oct 2007 21:47:39 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00H0LHRDSD00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 13:47:37 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG00DZ7HRBC130@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 13:47:35 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l95KlNrK027596; Fri, 05 Oct 2007 16:47:23 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l95KlNq4027593; Fri, 05 Oct 2007 16:47:23 -0400 (EDT) Date: Fri, 05 Oct 2007 16:47:22 -0400 From: James Carlson Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <20071005204024.GX19909@Sun.COM> To: Nicolas Williams Cc: John Plocher , Don Cragun , Thomas.Haynes@sun.com, PSARC-ext@sun.com Message-id: <18182.41690.929623.343360@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> <47069D2A.7030801@Sun.Com> <18182.41060.44902.834525@gargle.gargle.HOWL> <20071005204024.GX19909@Sun.COM> Status: RO Content-Length: 775 Nicolas Williams writes: > On Fri, Oct 05, 2007 at 04:36:52PM -0400, James Carlson wrote: > > If the project team is actually making _more_ file systems set > > S_TRIGGER, then I agree that the bug has been crowbared open a bit, > > and that might well be enough to push me into the "opposed" camp. > > Isn't that what's intended here? that the trigger flag will be used on > NFSv4 paths that when crossed trigger a mount? OK; I saw only the autofs part of this. You're right that if they're extending, then we've got a bigger issue to deal with. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From robert.thurlow@Sun.COM Fri Oct 5 15:51:56 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l95MptHI011643 for ; Fri, 5 Oct 2007 15:51:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l95MmZZa027124; Fri, 5 Oct 2007 23:48:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPG00801ND24900@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 15:48:38 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPG00DK7ND2BY90@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Oct 2007 15:48:38 -0700 (PDT) Received: from [10.7.250.28] (punchin-client-10-7-250-28.SFBay.Sun.COM [10.7.250.28]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l95Mmbwr913204; Fri, 05 Oct 2007 15:48:37 -0700 (PDT) Date: Fri, 05 Oct 2007 16:48:36 -0600 From: Robert Thurlow Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <18182.41060.44902.834525@gargle.gargle.HOWL> To: James Carlson Cc: John Plocher , Thomas.Haynes@Sun.COM, Don Cragun , PSARC-ext@Sun.COM Message-id: <4706BF44.10802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> <47069D2A.7030801@Sun.Com> <18182.41060.44902.834525@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1349 James Carlson wrote: > John Plocher writes: >> James Carlson wrote: >>> How's that? >> The difference I see is that in the original case, only autofs >> triggered mount points were handled by this code path; in the >> new code allows anything that sets S_TRIGGER will, uhm, trigger >> this code path. >> >> As long as only autofs does it, things are identical. If anything >> else does... >> >> At least, that's how I parsed it. > > That's what appears to me to make it identical. > > If the project team is actually making _more_ file systems set > S_TRIGGER, then I agree that the bug has been crowbared open a bit, > and that might well be enough to push me into the "opposed" camp. We do plan to use this beyond autofs. That's kinda the point :-) But we think it is identical architecturally. What we're implementing is very much like autofs triggers created under /net. We don't know a priori where they are like we do with the regular automounter maps, but when we need to know, we go look at the server and create nodes on the fly. With /net, we use the MOUNT protocol and parse the output to create triggers. With mirror mounts, we use the NFSv4 "server namespace" support to create triggers by noting changes in the fsid. We can do this better and in more cases with mirror mounts, but it's not different in the end goal. Rob T From Rich.Brown@sun.com Fri Oct 5 23:17:43 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l966HgZP026280 for ; Fri, 5 Oct 2007 23:17:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l966ERAU017891 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 6 Oct 2007 14:14:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPH00C01804R100@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 05 Oct 2007 23:14:28 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPH00BMP8034I10@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 05 Oct 2007 23:14:28 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l966EREo023117 for ; Sat, 06 Oct 2007 06:14:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPH006017WU6N00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 06 Oct 2007 00:14:27 -0600 (MDT) Received: from [129.147.9.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPH00291803NR20@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 06 Oct 2007 00:14:27 -0600 (MDT) Date: Sat, 06 Oct 2007 01:14:27 -0500 From: Rich Brown Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <4706A2A4.7070002@Sun.COM> Sender: Rich.Brown@sun.com To: psarc-ext@sun.com Message-id: <470727C3.8030907@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> <47069D2A.7030801@Sun.Com> <18182.41060.44902.834525@gargle.gargle.HOWL> <4706A2A4.7070002@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1103 Rich Brown wrote: > > The team just met with Don Cragun to discuss the concerns. We've all > agreed on how to proceed. Notes coming out shortly and I'll summarize > on the alias. > > Rich - Don and the team agreed to the following: * The case would continue, but the commitment level would be changed to "Consolidation Private" since the only known use of this is for the find/nftw(3c) problem. This would also eliminate the proposed change to the stat(2) man page. * Rich will submit a CR describing the existing security holes. Don, Jim Carlson, and the team will be on the Interest List. (I'm currently investigating what security holes still exist and will submit the CR with my findings.) * If the team find an additional use for S_IFTRIGGER, then the team will submit a fast-track to upgrade the commitment level. * When the security issues are fixed (either by Jim Carlson's fstatat() suggestion or some other solution), then obsolete/remove the S_IFTRIGGER bit (assuming the team hasn't upgraded the commitment level). From Joerg.Schilling@fokus.fraunhofer.de Sat Oct 6 03:51:09 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l96Ap9D0008121 for ; Sat, 6 Oct 2007 03:51:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l96AlvZc000441; Sat, 6 Oct 2007 03:47:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPH00701KNW8F00@nwk-avmta-2.sfbay.sun.com>; Sat, 06 Oct 2007 03:47:56 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPH00BU4KNWVE80@nwk-avmta-2.sfbay.sun.com>; Sat, 06 Oct 2007 03:47:56 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l96AjrUm008631; Sat, 06 Oct 2007 10:47:56 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay42i.sun.com with ESMTP id BT-MMP-972966; Sat, 06 Oct 2007 10:47:55 +0000 (Z) Received: from relay41i.sun.com ([192.5.209.70] [192.5.209.70]) by mms49es.sun.com with ESMTP id BT-MMP-1952623; Sat, 06 Oct 2007 10:47:53 +0000 (Z) Received: from mailgwb1.fraunhofer.de ([153.96.87.18] [153.96.87.18]) by relay4i.sun.com with ESMTP id BT-MMP-20421501; Sat, 06 Oct 2007 10:47:53 +0000 (Z) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de (8.13.5+/8.13.4) with ESMTP id l96AlquR026528; Sat, 06 Oct 2007 12:47:52 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.13.5+/8.13.4) with ESMTP id l96AlplA026494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 06 Oct 2007 12:47:52 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id l96Alpda029784; Sat, 06 Oct 2007 12:47:51 +0200 (MEST) Received: from burner ([10.147.65.166]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Sat, 06 Oct 2007 12:47:51 +0200 Date: Sat, 06 Oct 2007 12:47:50 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <470727C3.8030907@Sun.COM> To: Rich.Brown@sun.com, psarc-ext@sun.com Message-id: <470767d6.eAWzwum9wwPh3Su0%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 X-Fraunhofer-Email-Policy: accepted References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> <47069D2A.7030801@Sun.Com> <18182.41060.44902.834525@gargle.gargle.HOWL> <4706A2A4.7070002@Sun.COM> <470727C3.8030907@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 06 Oct 2007 10:47:51.0535 (UTC) FILETIME=[57C407F0:01C80806] Status: RO Content-Length: 995 Rich Brown wrote: > > Rich Brown wrote: > > > > The team just met with Don Cragun to discuss the concerns. We've all > > agreed on how to proceed. Notes coming out shortly and I'll summarize > > on the alias. > > > > Rich > > > - Don and the team agreed to the following: > > * The case would continue, but the commitment level would be changed > to "Consolidation Private" since the only known use of this is for > the find/nftw(3c) problem. This would also eliminate the proposed > change to the stat(2) man page. This is definitely an incorrect assumption. mkisofs uses libfind and libfind is not based on nftw but on the portable treewalk. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Rich.Brown@Sun.COM Tue Oct 9 20:44:19 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9A3iJiN025272 for ; Tue, 9 Oct 2007 20:44:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9A3f2lT008693 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 9 Oct 2007 20:41:02 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPO00709FKET200@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Tue, 09 Oct 2007 21:41:02 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPO007XPFKD2FD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Tue, 09 Oct 2007 21:41:01 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9A3f1mr026931 for ; Wed, 10 Oct 2007 03:41:01 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPO00D01F12VD00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 09 Oct 2007 21:41:01 -0600 (MDT) Received: from [129.147.9.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPO00517FJJNB60@mail-amer.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 09 Oct 2007 21:40:37 -0600 (MDT) Date: Tue, 09 Oct 2007 22:40:30 -0500 From: Rich Brown Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <470727C3.8030907@Sun.COM> Sender: Rich.Brown@Sun.COM To: psarc-ext@Sun.COM Message-id: <470C49AE.9050204@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_phFE3jVcFimjmG2Ae161Fg)" X-PMX-Version: 5.2.0.264296 References: <200710051903.l95J3TWm023783@spartan.SFBay.Sun.COM> <18182.37469.358970.911832@gargle.gargle.HOWL> <20071005195830.GU19909@Sun.COM> <18182.39287.767227.501357@gargle.gargle.HOWL> <47069D2A.7030801@Sun.Com> <18182.41060.44902.834525@gargle.gargle.HOWL> <4706A2A4.7070002@Sun.COM> <470727C3.8030907@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 10141 This is a multi-part message in MIME format. --Boundary_(ID_phFE3jVcFimjmG2Ae161Fg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT After discussing the security issues with the concerned PSARC members, the team has decided to modify the proposed solution. The proposal no longer includes adding S_IFTRIGGER as a bit in st_mode and S_ISTRIGGER() as a macro. The team agrees with PSARC's advice and proposes to add the AT_TRIGGER bit to the flag parameter of fstatat(). The first attachment (spec_update.txt) is the updated spec with diff-marks. The second attachment (stat2_diffs.txt) is the diff of the update to the stat(2) man page. I'm extending the timer to this Friday, 10/12, to allow time for any additional questions to settle. The team will be available for questions at the PSARC meeting. Rich --Boundary_(ID_phFE3jVcFimjmG2Ae161Fg) Content-type: text/plain; name=spec_update.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec_update.txt == PROBLEM OVERVIEW nftw(3C) is a routine in libc which is the "new file tree walk". It recursively calls walk() to traverse a directory tree. One main consumer of it is find(1). There are several flags that control how walk() behaves: FTW_MOUNT directs walk() not to cross mountpoints FTW_PHYS directs walk() not to follow symbolic links. The walk() routine uses stat() to test each component that it encounters to ensure that it does not violate the requested behavior. The following code snippet succinctly captures the security test and the window of opportunity: struct stat statPre; struct stat statFile; DIR *pdir; stat(szPath, &statPre); pdir = opendir(szPath); fstat(pdir->dd_fd, &statFile); if (statPre.st_ino != statFile.st_ino || statPre.st_dev != statFile.st_dev) { return(EAGAIN); } There is a window between the stat() and opendir() calls when the user might move directory contents (an innocent case we need to avoid) or use a symlink to get outside of the directory hierarchy (a security breach). If the results of the stat() do not match those of the fstat(), then assume that there is some problem and return to the caller. find(1) will for example report: find: cannot open /mnt: Resource temporarily unavailable A problem with this test occurs when the filesystem is of type "autofs" (PSARC 1992/024). In that case, the directory entry, whose name is given by szPath, is a trigger mount - a mount occurs when the | directory is entered. By definition, getting attributes on the directory (i.e., stat()) does not constitute entering the directory, but the opendir() does, which triggers an autofs mount. This leads to a false positive case. The code is not able to detect that a trigger mount occured beneath it - the st_ino and st_dev are expected to not match. As expected, if the user were to immediately retry the application, it would now succeed. The mount has been established and the results from the stat() will match the fstat(). The current code addresses this by doing a strcmp() on st_fstype to determine if it is an autofs filesystem (see fix 6198351). If so, then statPre is refreshed after the opendir(). This was deemed safe in | that the kernel owns the contents of the autofs filesystem. While | the kernel does own the contents, it is possible for changes to occur | for example in /net which would allow a symlink type exploit to | happen to a directory which was a trigger mount. By unilaterally | allowing the exception, we blind ourselves to this act. | If we add the test from the current code for ntfw()/walk(), the code snippet would now look like this: struct stat statPre; struct stat statFile; DIR *pdir; stat(szPath, &statPre); pdir = opendir(szPath); if (statPre.st_fstype[0] == 'a' && strcmp(statPre.st_fstype, "autofs") == 0) { /* * this dir is on autofs */ fstat(pdir->fd->dd_fd, &statPre) } fstat(pdir->dd_fd, &statFile); if (statPre.st_ino != statFile.st_ino || statPre.st_dev != statFile.st_dev) { return(EAGAIN); } With the addition of mirror mounts for NFSv4 (see PSARC 2007/416), we have another case where trigger mounts can cause a false positive. Also note that other NFSv4 features, such as referrals and migration will employ trigger mounts as the integral interface to remote filesystems. We could once again try checking the st_fstype for "nfs4" to for exception checking, but this check will fail for these reasons: 1) st_fstype for "nfs3" and "nfs4" is truncated to "nfs" for backwards compatibility in 3rd party applications. I.e., this would lead to us allowing exemptions for all directory entries on all versions of nfs. The problem is that we should only allow exemptions for directories | which are "nfs4" and mirror mount trigger points. 2) All nfs filesystems are not strictly controlled in the kernel as with the autofs filesystem. I.e., it is possible for an user application to mangle the directory tree. The point here is that an autofs filesystem is not directly writable by the user. The only objects in an autofs filesystem are | automount trigger points, and then cannot be manipulated. The user can not move directory hierarchies around in an autofs filesystem. So walk() can be a bit relaxed. With a nfs filesystem, walk() does not have that luxury. === PROPOSED SOLUTION The solution is to atomically force the stat() call to mount the | new filesystem and return the attributes of the root vnode rather than | that of the vnode which has been mounted on. This guarantees that | we have accurate information and we do not introduce further windows | of opportunity. | In order to do this, we propose to add a new bit, AT_TRIGGER, to the | flags field of the parameters to fstatat(2). This information would be | passed down through the system call and into the VOP interface to | VOP_GETATTR() using a new bit, ATTR_TRIGGER. This bit informs the file | system that, if the vnode is a trigger-mount, the file system should | mount the file system before performing the operation. | In particular, we would add to sys/fcntl.h: | #define AT_TRIGGER 0x2 | And we would add to sys/vnode.h: | #define ATTR_TRIGGER 0x40 /* If vnode is a trigger mount, mount first */ | The code snippet would now look like this: struct stat statPre; struct stat statFile; DIR *pdir; fstatat(0, szPath, &statPre, AT_TRIGGER); | pdir = opendir(szPath); fstat(pdir->dd_fd, &statFile); * if (statPre.st_ino != statFile.st_ino || statPre.st_dev != statFile.st_dev) { return(EAGAIN); } Note that this proposal provides for better security than what is | currently in Nevada. The resetting of the stat buffer as an | exception did introduce a hole. This proposal closes that hole, | but does not seek to address any other security issue. In particular, | the code will react to a compromised server in exactly the same | as before. | === EXPORTED INTERFACE TABLE |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== | | | | AT_TRIGGER | Committed | This | New bit value | | | Document | for flag parameter | | | | to fstatat() | | | | | ATTR_TRIGGER | Consolidation | | New bit passed to | | Private | | VOP_GETATTR() | | | | indicating that the| | | | file system should | | | | mount the new FS if| | | | the vnode is a | | | | trigger mount. | --Boundary_(ID_phFE3jVcFimjmG2Ae161Fg) Content-type: text/plain; name=stat2_diffs.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=stat2_diffs.txt < the flag argument is AT_SYMLINK_NOFOLLOW, the function < behaves like lstat() and does not automatically follow sym- < bolic links. See fsattr(5). --- > AT_SYMLINK_NOFOLLOW is set in the flag argument, > the function behaves like lstat() and does not automatically > follow symbolic links. See fsattr(5). If AT_TRIGGER is set > in the flag argument, then if the vnode is a > trigger mount point, the mount is performed and the function > returns the attributes of the root of the mounted filesystem. --Boundary_(ID_phFE3jVcFimjmG2Ae161Fg)-- From don.cragun@sun.com Wed Oct 10 08:48:17 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9AFmHeF007383 for ; Wed, 10 Oct 2007 08:48:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9AFj1N4005320; Wed, 10 Oct 2007 08:45:02 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPP00D11D311E00@brm-avmta-1.central.sun.com>; Wed, 10 Oct 2007 09:45:01 -0600 (MDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPP003W1D2ZVM80@brm-avmta-1.central.sun.com>; Wed, 10 Oct 2007 09:44:59 -0600 (MDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id l9AFiwLJ029427; Wed, 10 Oct 2007 08:44:59 -0700 (PDT) Date: Wed, 10 Oct 2007 08:44:59 -0700 (PDT) From: Don Cragun Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] To: Rich.Brown@sun.com Cc: psarc-ext@sun.com Reply-to: Don Cragun Message-id: <200710101544.l9AFiwLJ029427@spartan.SFBay.Sun.COM> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: OAujHV+jpHXt6FdT14RT6g== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1044 >Date: Tue, 09 Oct 2007 22:40:30 -0500 >From: Rich Brown ... ... ... >The team agrees with PSARC's advice and proposes to add the AT_TRIGGER bit to >the flag parameter of fstatat(). AT_TRIGGER may be useful in standards conforming applications using extensions, but the standards don't allow us to pollute the namespace with this symbol. I strongly suggest renaming this to _AT_TRIGGER (at least in standards conforming compilation modes) until this flag is added to a future revision of the standards (if that ever happens). Has adding this flag to the standards been discussed with the other UNIX System vendors (Apple, HP, IBM) or Linux system vendors? > >The first attachment (spec_update.txt) is the updated spec with diff-marks. The This case needs to be extended to update nftw64() as well as nftw(). >second attachment (stat2_diffs.txt) is the diff of the update to the stat(2) man >page. Don't we also need an fsattr(5) man page update for the section on fstatat()? - Don ... ... ... > > Rich From Thomas.Haynes@Sun.COM Wed Oct 10 09:39:10 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9AGdAAa010909 for ; Wed, 10 Oct 2007 09:39:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9AGZqFA026147; Wed, 10 Oct 2007 17:35:52 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPP00H07FFSPF00@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Oct 2007 09:35:52 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPP00DEYFFQUQ60@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Oct 2007 09:35:51 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9AGZo4s013016; Wed, 10 Oct 2007 16:35:50 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPP00901DL69C00@mail-amer.sun.com> (original mail from Thomas.Haynes@Sun.COM); Wed, 10 Oct 2007 10:35:50 -0600 (MDT) Received: from [192.168.2.115] ([72.198.16.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPP005VQFFQVQD0@mail-amer.sun.com>; Wed, 10 Oct 2007 10:35:50 -0600 (MDT) Date: Wed, 10 Oct 2007 11:34:08 -0500 From: Tom Haynes Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <200710101544.l9AFiwLJ029427@spartan.SFBay.Sun.COM> Sender: Thomas.Haynes@Sun.COM To: Don Cragun Cc: Rich.Brown@Sun.COM, psarc-ext@Sun.COM Message-id: <470CFF00.10000@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710101544.l9AFiwLJ029427@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1363 Don Cragun wrote: >> Date: Tue, 09 Oct 2007 22:40:30 -0500 >> From: Rich Brown >> > ... ... ... > >> The team agrees with PSARC's advice and proposes to add the AT_TRIGGER bit to >> the flag parameter of fstatat(). >> > > AT_TRIGGER may be useful in standards conforming applications using > extensions, but the standards don't allow us to pollute the namespace > with this symbol. I strongly suggest renaming this to _AT_TRIGGER (at > least in standards conforming compilation modes) until this flag is > added to a future revision of the standards (if that ever happens). > > We will do that. > Has adding this flag to the standards been discussed with the other > UNIX System vendors (Apple, HP, IBM) or Linux system vendors? > > No, we just bite the bullet yesterday with respect to taking this approach. >> The first attachment (spec_update.txt) is the updated spec with diff-marks. >> > The > > This case needs to be extended to update nftw64() as well as nftw(). > Yes, we will do that. > >> second attachment (stat2_diffs.txt) is the diff of the update to the stat(2) >> > man > >> page. >> > > Don't we also need an fsattr(5) man page update for the section on > fstatat()? > > Yes, we will need to do that. > - Don > > ... ... ... > >> Rich >> > > > From Rich.Brown@sun.com Wed Oct 10 11:38:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9AIcltg018706 for ; Wed, 10 Oct 2007 11:38:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9AIZMGP027870 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 10 Oct 2007 19:35:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPP00003KZ5X500@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 10 Oct 2007 11:35:29 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPP00B8SKZ51370@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 10 Oct 2007 11:35:29 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9AIZSAm028803 for ; Wed, 10 Oct 2007 18:35:28 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPP00C01KTAT900@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 10 Oct 2007 12:35:28 -0600 (MDT) Received: from [129.147.9.37] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPP00C28KYY76F0@mail-amer.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 10 Oct 2007 12:35:23 -0600 (MDT) Date: Wed, 10 Oct 2007 13:35:22 -0500 From: Rich Brown Subject: Re: Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007] In-reply-to: <470CFF00.10000@sun.com> Sender: Rich.Brown@sun.com To: psarc-ext@sun.com Message-id: <470D1B6A.8080801@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710101544.l9AFiwLJ029427@spartan.SFBay.Sun.COM> <470CFF00.10000@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 550 This case was approved at today's PSARC meeting. The team has updated the spec and have provided diff output for the stat(2) and fsattr(5) man pages. I've deposited the following files in the case directory: spec.txt - Updated final spec stat2_diffs.txt - diff output for stat(2) fsattr5_diffs.txt - diff output for fsattr(5) I also renamed the IAM file (IAM.Add__AT_TRIGGER_to_fstatat) and changed the project name (Add _AT_TRIGGER to fstatat). I sent mail to John Plocher with the new IAM information. Thanks for the help on this, Rich