From Calum.Mackay@Sun.COM Fri May 11 14:56:29 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4BLuTlf018452 for ; Fri, 11 May 2007 14:56:29 -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 l4BLtPYk021963 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 11 May 2007 14:55:25 -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 <0JHW00B01CWCTG00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 11 May 2007 14:55:24 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHW0089KCWB3G10@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 11 May 2007 14:55:24 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4BLtNG7009936 for ; Fri, 11 May 2007 21:55:23 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHW00B01CVEQ100@d1-emea-10.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 11 May 2007 22:55:23 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHW000D1CW8DD74@d1-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 11 May 2007 22:55:23 +0100 (BST) Date: Fri, 11 May 2007 22:55:18 +0100 From: Calum Mackay Subject: 2007/268 Support for CIFS share reservations Sender: Calum.Mackay@Sun.COM To: psarc-ext@Sun.COM, Bob Mastors Message-id: <4644E646.4050603@sun.com> Organization: Sun Microsystems 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 User-Agent: Thunderbird 3.0a1 (X11/20070504) Status: RO Content-Length: 8596 I'm sponsoring the following fast-track for Bob Mastors. The timer is set to Weds 23rd May. The case seeks Minor binding. cheers, calum. Support for CIFS share reservations CONTEXT This fast-track was spun off of the CIFS Service (PSARC 2006/715) case along with: PSARC 2007/218 caller_context_t in all VOPs PSARC 2007/227 VFS Feature Registration and ACL on Create PSARC 2007/244 ZFS case-insensitive support Although each of these changes are part of the bigger picture, they have been broken down into smaller pieces so each gets the attention it deserves. The project team intends to put all of these changes into ON in a single putback. NOTE: The VFSDEF_VERSION number in sys/vfs.h will be bumped from 3 to 4 in order to prevent unbundled file system kernel modules with the old signatures from loading. Once the unbundled file system modules are updated with the new signatures and recompiled, they will also pick up the new VFSDEF_VERSION number and be allowed to load. INTRODUCTION This fast-track proposes a set of changes to support the CIFS Service (PSARC 2006/715). This case builds on and modifies PSARC 2000/007 "Locking and File Sharing Support". Summary of changes: 1) Support for Windows style delete share reservation 2) Change NBMAND behavior (PSARC 2000/007) for rename check 3) Remove restriction on deny read access (PSARC 2000/007) 4) Modify vn_openat() such that local opens of a file obtain a share reservation 5) Coordinate mmap() requests with share reservation requests SUPPORT FOR DELETE SHARE RESERVATION The CIFS service requires the ability to set a share reservation with access and deny values for file removal. This will be done using VOP_SHRLOCK(). The following f_access value will be added to sys/fcntl.h: #define F_RMACC 0x4 /* private flag: Delete share access */ The following f_deny value will be added to sys/fcntl.h: #define F_RMDNY 0x20 /* private flag: Deny delete share access */ These values are only allowed on regular files on a file system mounted with the "nbmand" option. These values are only allowed with the F_SHARE_NBMAND cmd to VOP_SHRLOCK. The new behaviors caused by these values are as follows: 1. A request for a new share reservation with F_RMDNY (deny delete) will fail with EAGAIN if a share reservation exists with F_RMACC (access delete). 2. A request for a new share reservation with F_RMACC (access delete) will fail with EAGAIN if a share reservation exists with F_RMDNY (deny delete). NAME CHANGE RESTRICTION ON SHARE RESERVATIONS Currently, if a file system is mounted with "nbmand" set then a file cannot be renamed if any other process has a share reservation on the file. For windows compatibility the algorithm will be replaced with the following: A rename will fail with EACCES because of a sharing violation under the following conditions: - The source file has a share reservation from another process that has "write" or "remove" share access. - The source file has a share reservation from another process that has "read" share access and deny "remove". REMOVE RESTRICTION ON DENY READ ACCESS The final materials for PSARC 2000/007 states the following: 2. security One of the issues that came up during PSARC review was denial of service attacks. The project team said that a process would have to have write access to a file in order to deny read access to other processes. After the Commitment#2 review the project team realized that although this is true for record locks, it is not true for share reservations. The project team proposes to fix this by changing the F_SHARE_NBMAND fcntl so that if the "deny read" bit is set, the file must have been opened with write permission. The CIFS server team requests that this restriction be dropped. Sun is committed to fully supporting CIFS and this restriction breaks CIFS/Windows semantics. The proposed behavior is that "deny read" can be set on a file without regard to how the file was opened for access but *ONLY* when the "nbmand" mount option has been set on the file system. In order to help mitigate potential security issues, the mount(1m) manual page will be changed from: Do not use the nbmand option with /, /var and /usr. to: Do not use the nbmand option with the following file systems to avoid the possibility of obtaining mandatory locks on system files: / /etc /var /proc /dev /devices /system/contract /system/object /etc/mnttab /etc/dfs/sharetab SHARE RESERVATIONS FOR LOCAL OPENS The way to coordinate and enforce the CIFS share reservation rules at open(2) time with local opens is to ensure that all local opens on a CIFS-shared file system have a share reservation. (NFSv4 already provides share reservations for opens. NFSv2/3 coordinate with the lock manager for share reservations.) To address this, when a file system is mounted with the "nbmand" mount option, a local open of the file will also obtain a share reservation on that file. For example, an open of a file for FREAD will cause a share reservation to be obtained via VOP_SHRLOCK with an access of F_RDACC (access read) and deny of F_NODENY (deny none). COORDINATE SHARE RESERVATIONS WITH MMAP REQUESTS One of the concerns listed in the PSARC opinion for 2000/007 was that NBMAND locks were not coordinated with mmap(). This case proposes to change this such that: - Attempts to acquire a share reservations or byte range lock on a file will fail if the file is mmap()ed and the nbmand mount option is in effect. - mmap() on a file will fail if there is a conflicting share reservation or byte range lock on that file and the nbmand mount option is in effect. The limitation is that: - a process will not be able to mmap() a file on which it holds a "conflicting" share reservation or byte range lock. - a process will not be able to obtain a share reservation or byte range lock on a file on which it has a "conflicting" mmap(). LIMITATIONS When the "nbmand" mount option is set, a share reservation will be obtained whenever a process opens a local file. If the process attempts to open that file a second time and *if* the VOP_OPEN() fails (which is not a likely scenario), then removing the process' second share reservation will also remove the first. This is a consequence of vn_openat() not having sufficient information (such as a file descriptor) about the open request. Also, if a process has opened a file multiple times and has locks (including share reservations) on that file, then the first close(2) on the file will remove (unlock) all locks on the file. This behavior exists today and is documented in the close(2) man page: All outstanding record locks owned by the process on the file associated with the file descriptor will be removed (that is, unlocked). The ramification of the above scenarios is: If a CIFS process opens a file with a deny mode (share reservation specifying that other types of opens be denied) and a local process has that file open but has lost its share reservations, then the local process' read/write system call will fail with EACCESS. The above behavior of having a conflicting read or write operation fail with EACCES was approved with PSARC 2000/007. (See "fcntl.2" under "final.materials" in the case directory.) FUTURE WORK The project team is working on a fully integrated design where the share/deny modes are passed directly to VOP_OPEN() and VOP_CLOSE(). This will eliminate the need to call VOP_SHRLOCK() to acquire/release a share reservation. There are still several design issues which need to be resolved and the team is not prepared to present the design at this time. In the interest of business needs and product schedules, the interim solution is to make the modifications presented in this case to satisfy the short-term needs of the product. EXPORTED INTERFACES: |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Consolidation |This | F_RMACC |Private |Document | Delete share access | | | F_RMDNY | | | Deny delete share | | | access | | | From Calum.Mackay@sun.com Wed May 23 10:34:19 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 l4NHYI17008483 for ; Wed, 23 May 2007 10:34:19 -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 l4NHWaYt006159 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Wed, 23 May 2007 18:33:05 +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 <0JII00H018R1OO00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 May 2007 11:33:01 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JII005C78QZ0K90@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 May 2007 11:33:00 -0600 (MDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4NHWxoN022475 for ; Wed, 23 May 2007 17:32:59 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JII00C018MJUE00@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 May 2007 18:32:59 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JII00HG98QUX447@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 23 May 2007 18:32:57 +0100 (BST) Date: Wed, 23 May 2007 18:32:52 +0100 From: Calum Mackay Subject: Re: 2007/268 Support for CIFS share reservations In-reply-to: <4644E646.4050603@sun.com> Sender: Calum.Mackay@sun.com To: Calum Mackay Cc: PSARC-EXT@sun.com, Bob Mastors Message-id: <46547AC4.5050603@sun.com> Organization: Sun Microsystems 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: <4644E646.4050603@sun.com> User-Agent: Thunderbird 3.0a1 (X11/20070504) Status: RO Content-Length: 67 This fast-track was approved at today's PSARC meeting. cheers, c.