ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
This case was approved during today's PSARC meeting. -tim
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
We seem to have no membership participation on this email thread. So, +1 -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USAmain: +1(651) 554-1500 -
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
On Mon, Oct 20, 2008 at 11:25:28AM -0600, Doug McCallum wrote: > >NFS supports share ACLs of a sort now in the form of host/negroup lists. > > > >Shouldn't CIFS also support such an ACL mechanism? > > > The NFS host based access control will be putback into Nevada in build 102. Er, NFS has had it forever. Do you mean that CIFS will also have it in build 102? If so, that's really cool. > >I pointed out that NFS has a notion of shares and share ACLs, but I see > >that the notion of share ACLs for CIFS is based on Windows file ACLs, as > >opposed to the NFS share-ACL-as-host/netgroup-list that we have now. > > > >In NFS there's no TreeConnect-type operation, but a share-level ACL can > >still be applied in operations that deal with paths. > > Correct. Can we expect to see a future case adding share-level ACLs (beyond host-based ACLs) to the NFS server?
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
On Mon, Oct 20, 2008 at 11:19:34AM -0600, Doug McCallum wrote: > Nicolas Williams wrote: > >On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > > > >>CIFS is the only protocol we currently support that has the > >>concept of shares (resources in sharemgr/share terms) so this > >>implementation will initially only provide support for CIFS. > >> > > > >That can't possibly be right. NFS has long had a concept of shares, and > >share ACLs too. > > The NFS host access control (which is being added to SMB as well) is > not ACL based. I was specifically responding to the claim about the notion of shares. > They are strictly based off of the client IP address and not based on > the user's ID. That's true, but many people call these ACLs. An ACL need not have a particular form in order to be deserving of the term "ACL." Nico --
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 11:25:28AM -0600, Doug McCallum wrote: > >>> NFS supports share ACLs of a sort now in the form of host/negroup lists. >>> >>> Shouldn't CIFS also support such an ACL mechanism? >>> >>> >> The NFS host based access control will be putback into Nevada in build 102. >> > > Er, NFS has had it forever. Do you mean that CIFS will also have it in > build 102? If so, that's really cool. > Sorry. I did mean NFS style host based access control on CIFS. > >>> I pointed out that NFS has a notion of shares and share ACLs, but I see >>> that the notion of share ACLs for CIFS is based on Windows file ACLs, as >>> opposed to the NFS share-ACL-as-host/netgroup-list that we have now. >>> >>> In NFS there's no TreeConnect-type operation, but a share-level ACL can >>> still be applied in operations that deal with paths. >>> >> Correct. >> > > Can we expect to see a future case adding share-level ACLs (beyond > host-based ACLs) to the NFS server? > There aren't any current plans. The CIFS share-level ACLs are part of the Microsoft specification so we need to get those added. It seems like a reasonable RFE for NFS to provide an alternative namespace using resource names.
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 11:19:34AM -0600, Doug McCallum wrote: > >> Nicolas Williams wrote: >> >>> On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: >>> >>> CIFS is the only protocol we currently support that has the concept of shares (resources in sharemgr/share terms) so this implementation will initially only provide support for CIFS. >>> That can't possibly be right. NFS has long had a concept of shares, and >>> share ACLs too. >>> >> The NFS host access control (which is being added to SMB as well) is >> not ACL based. >> > > I was specifically responding to the claim about the notion of shares. > NFS has shares, but not the same concept. The parenthetical addition of the "resources" terminology was intended to clarify the difference. NFS doesn't really have the same definition. The terminology can be confusing between protocols that have similar, but slightly different, semantics. > >> They are strictly based off of the client IP address and not based on >> the user's ID. >> > > That's true, but many people call these ACLs. An ACL need not have a > particular form in order to be deserving of the term "ACL." > NFS hasn't documented them exactly as ACLs, but I see where you are coming from. Access lists and access control lists are similar. We tend to refer to the NFS style as host based access and the SMB ACLs as share level ACLs.
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > During SMB "tree connect" is will be necessary to get the ACL > that is set on a share and use it to setup the initial access. > The ACLs are expected to be stored in objects within a new > directory under .zfs. /dataset/.zfs/shares/ will contain > objects with names that match the shares defined on that > dataset. Just before the tree connect, the sharename will be > looked up in the .zfs/shares directory, the ACLs obtained and > then processed relative to the user making the tree > connect. The result of processing the ACL will be used to > determine access. > > The ZFS changes will include a means to create/remove the > share objects within the new .zfs/shares directory. Once > created, it will also be possible to use the standard ACL > interfaces to get/set ACLs on these new objects. That is, > chmod and ls will be used. NFS supports share ACLs of a sort now in the form of host/negroup lists. Shouldn't CIFS also support such an ACL mechanism? > Note that there can be multiple shares (resources) for any > given path that is shared. This mechanism allows setting > different ACLs for the same path depending on the name it is > associated with. Interesting. I believe there's nothing in the NFSv4 protocol precluding the same feature, but that our NFS server doesn't have this. Out of curiosity: is there a need for this (multiple shares for a given path/dataset) in NFS? > CIFS is the only protocol we currently support that has the > concept of shares (resources in sharemgr/share terms) so this > implementation will initially only provide support for CIFS. I pointed out that NFS has a notion of shares and share ACLs, but I see that the notion of share ACLs for CIFS is based on Windows file ACLs, as opposed to the NFS share-ACL-as-host/netgroup-list that we have now. In NFS there's no TreeConnect-type operation, but a share-level ACL can still be applied in operations that deal with paths. Nico --
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > CIFS is the only protocol we currently support that has the > concept of shares (resources in sharemgr/share terms) so this > implementation will initially only provide support for CIFS. That can't possibly be right. NFS has long had a concept of shares, and share ACLs too. Nico --
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > >> During SMB "tree connect" is will be necessary to get the ACL >> that is set on a share and use it to setup the initial access. >> The ACLs are expected to be stored in objects within a new >> directory under .zfs. /dataset/.zfs/shares/ will contain >> objects with names that match the shares defined on that >> dataset. Just before the tree connect, the sharename will be >> looked up in the .zfs/shares directory, the ACLs obtained and >> then processed relative to the user making the tree >> connect. The result of processing the ACL will be used to >> determine access. >> >> The ZFS changes will include a means to create/remove the >> share objects within the new .zfs/shares directory. Once >> created, it will also be possible to use the standard ACL >> interfaces to get/set ACLs on these new objects. That is, >> chmod and ls will be used. >> > > NFS supports share ACLs of a sort now in the form of host/negroup lists. > > Shouldn't CIFS also support such an ACL mechanism? > The NFS host based access control will be putback into Nevada in build 102. It has been a long standing case for adding Montana equivalent support to NFS and CIFS. > >> Note that there can be multiple shares (resources) for any >> given path that is shared. This mechanism allows setting >> different ACLs for the same path depending on the name it is >> associated with. >> > > Interesting. I believe there's nothing in the NFSv4 protocol precluding > the same feature, but that our NFS server doesn't have this. > > Out of curiosity: is there a need for this (multiple shares for a given > path/dataset) in NFS? > There may not be anything that precludes it, but tI don't know of any implementations that provide for it. NFS essentially uses the "path" as the share name while SMB doesn't advertise the underlying path. If NFS implements an equivalent mechanism, this implementation would allow for it to be added. > >> CIFS is the only protocol we currently support that has the >> concept of shares (resources in sharemgr/share terms) so this >> implementation will initially only provide support for CIFS. >> > > I pointed out that NFS has a notion of shares and share ACLs, but I see > that the notion of share ACLs for CIFS is based on Windows file ACLs, as > opposed to the NFS share-ACL-as-host/netgroup-list that we have now. > > In NFS there's no TreeConnect-type operation, but a share-level ACL can > still be applied in operations that deal with paths. > Correct. Doug
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
Nicolas Williams wrote: > On Mon, Oct 20, 2008 at 10:43:31AM -0600, Tim Haley wrote: > >> CIFS is the only protocol we currently support that has the >> concept of shares (resources in sharemgr/share terms) so this >> implementation will initially only provide support for CIFS. >> > > That can't possibly be right. NFS has long had a concept of shares, and > share ACLs too. > The NFS host access control (which is being added to SMB as well) is not ACL based. They are strictly based off of the client IP address and not based on the user's ID. SMB share ACLs are just like file ACLs except that they are based on the share name. Each SMB share name for the same path can have its own set of ACLs. Doug
ACLs for CIFS/SMB shares [PSARC/2008/641 FastTrack timeout 10/27/2008]
I am sponsoring the following fasttrack for Doug McCallum. The case introduces ACLs to control access to SMB shares. Requested binding is minor. Timeout is 10/27/2008. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ACLs for CIFS/SMB shares 1.2. Name of Document Author/Supplier: Author: Doug McCallum 1.3 Date of This Document: 20 October, 2008 2. Project Summary 2.1. Project Description: Project is to provide ACLs at the CIFS/SMB "share" level. This is a standard feature in Microsoft implementations and is needed for completeness. ACLs on shares will only be supported on ZFS file systems. 2.2. Risks and Assumptions: Assumes changes to ZFS to provide a place to store the share ACLs. 4. Technical Description: 4.1. Details: During SMB "tree connect" is will be necessary to get the ACL that is set on a share and use it to setup the initial access. The ACLs are expected to be stored in objects within a new directory under .zfs. /dataset/.zfs/shares/ will contain objects with names that match the shares defined on that dataset. Just before the tree connect, the sharename will be looked up in the .zfs/shares directory, the ACLs obtained and then processed relative to the user making the tree connect. The result of processing the ACL will be used to determine access. The ZFS changes will include a means to create/remove the share objects within the new .zfs/shares directory. Once created, it will also be possible to use the standard ACL interfaces to get/set ACLs on these new objects. That is, chmod and ls will be used. Note that there can be multiple shares (resources) for any given path that is shared. This mechanism allows setting different ACLs for the same path depending on the name it is associated with. CIFS is the only protocol we currently support that has the concept of shares (resources in sharemgr/share terms) so this implementation will initially only provide support for CIFS. 4.2. Bug/RFE Number(s): 6582163 Access Control List (ACL) for Shares 4.3. In Scope: Only ZFS file systems will be supported. 4.4. Out of Scope: 4.5. Interfaces: Standard ACL interfaces will be used (ls, chmod). 4.6. Doc Impact: CIFS Administration Guide Modification to the zfs(1M) man page: -- When the "sharesmb" property is changed for a dataset, the dataset and any children inheriting the property are re-shared with the new options, only if the property was previously set to "off", or if they were shared before the property was changed. If the new property is set to "off", the file systems are unshared. +When SMB shares are created, the SMB share name appears as an +entry in the .zfs/shares directory. You can use the ls or +chmod command to display the share-level ACLs on the entries +in this directory. -- 4.7. Admin/Config Impact: N/A 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: N/A 4.10. Packaging & Delivery: N/A (existing packages will be used) 4.11. Security Impact: Doesn't change any existing security APIs or features. It does add an additional security mechanism. 4.12. Dependencies: N/A 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
