Hi. I'm trying to manually simulate the sharing capabilities of a NAS system, i.e., NFS and Samba, since the use it would be to share some data between applications servers running under linux (especifically, RHEL 5) and the bunch of users in the AD. So, I created some data and exported the point for both NFS and Samba. The access is basically right, but I've found a major issue that has stopped me and I'm not sure how to go on. The behaviour set from the security tab from a cifs client, is to propagate the acls, so if a user via cifs writes to the directory, the ACL does its work and the ACL tab seen from the cifs workstation works properly. Also, the linux user, via POSIX ACLs, can take advantage of the inherited ACL. But if the linux user creates a directory (either locally or via nfs), this is created with its umask and primary group, and thought the default POSIX ACLs are properly inherited (I've checked with getfacl) this doesn't happen with extended ones, so from cifs clients the access is forbidden. I've tried with filesystems formatted as ext3 and xfs, with acl options enabled. Taking that I've set "map acl inherit=yes" and "inherit acl=yes", together with several combinations of vfs objects with acl_tdb, acl_xattr and xattr_tdb. How can I get the linux user to inherit the ACLs of the parent directory when creating a new directory? Should I set anything in samba so the directories follow an inheritance?
acl_tdb, acl_xattr and xattr_tdb don't play too well together with native access. To get decent interoperability, you need to work without those modules and live with the restrictions the base linux system gives you. Please re-open this bug if you have a much more specific request and an exact description of the issue you're seeing, such that we can reproduce it easily.
Your hint about not melting all the modules together has helped to get better results, and in order to avoid future undesired issues with this, let me go a bit further. I've removed xattr_acl, so my relevant lines in the global section are these: acl map full control = No force unknown acl user = Yes inherit acls = Yes map acl inherit = Yes strict sync = Yes sync always = Yes map archive = No follow symlinks = No dos filemode = Yes vfs objects = xattr_tdb, acl_tdb My current new tests with this config, at this very moment, at least seem to keep the funcionality, so from the user point of view, it should work for him, but from an admin point of view, there's something that is not fully working as expected (maybe some bad configuration on my side, of course). The only problem is when creating files or dirs from a native user in a linux manchine. What I see right now is that inheritance, from posix point of view, is working nicely (i.e., getfacl shows the default acls and inheritance just like the parent), but the ntfs permission from the windows workstation lose the inheritance check that the parent has, and take the permissions for "this folder only". Creating elements from linux under these keep these behaviour on and on (I've tried creating only two levels deeper, it should be enough), and creating from cifs restore the inheritance check on the ones created from there. With this, and just to improve and make sure this "bleeding edge" is not lost in future releases, I wonder what is necessary in order for samba to retrieve the inheritance attribute, because I understand that according what I've read, that is taken from the default acl. This is the result of getfacl on the parent directory (I've replaced with "DOM" the AD domain): user::rwx group::--- group:DOM\134domain\040admins:rwx group:DOM\134gg_dti_admin_nas:rwx group:DOM\134gg_nasdes_epo_recepcion_esc:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:DOM\134domain\040admins:rwx default:group:DOM\134gg_dti_admin_nas:rwx default:group:DOM\134gg_nasdes_epo_recepcion_esc:rwx default:mask::rwx default:other::--- This is the result of getfacl in a "test" directory created from a linux machine right under the parent: user::rwx group::--- group:DOM\134domain\040admins:rwx group:DOM\134gg_dti_admin_nas:rwx group:DOM\134gg_nasdes_epo_recepcion_esc:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:DOM\134domain\040admins:rwx default:group:DOM\134gg_dti_admin_nas:rwx default:group:DOM\134gg_nasdes_epo_recepcion_esc:rwx default:mask::rwx default:other::--- And the getfacl from another directory created via cifs also right under the parent: user::rwx group::--- group:DOM\134domain\040admins:rwx group:DOM\134gg_dti_admin_nas:rwx group:DOM\134gg_nasdes_epo_recepcion_esc:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:DOM\134domain\040admins:rwx default:group:DOM\134gg_dti_admin_nas:rwx default:group:DOM\134gg_nasdes_epo_recepcion_esc:rwx default:mask::rwx default:other::--- If there's some work to be done for the vfs modules about issues like this, I take it, and I'd like to test the progress of them about this. If there's another reason for this, please let me know.
Please talk to the Linux kernel guys about adding full NTFS ACLs to the file systems.
(In reply to comment #3) > Please talk to the Linux kernel guys about adding full NTFS ACLs to the file > systems. OK, but then I want to be sure about where exactly the problem resides: at work, we're currently using a commercial NAS box, that is a linux, and the described inheritance works perfectly. I have access as non-root to testparm, and without being able to investigate futher and deep, I can only appreciate that a custom vfs_module is being used (vfs objects = libhivfs_scan, libhivfs_shadow_copy), and according to your suggestion, they should have patched the kernel for full NTFS ACLs, which looks very hard to be real situation. The only parameter for the share is "nt acl support = yes" (which is also added at the same point in my share definition and I forgot to add to my previous comment). Can you please confirm and, if possible, redirect to some source of information about the solution, whatever it is?
Ok. Please ask the NAS vendor for the full Samba sources including those modules. and upload them somewhere for review. It's GPL code. Thanks, Volker
(In reply to comment #5) > Ok. Please ask the NAS vendor for the full Samba sources including those > modules. and upload them somewhere for review. It's GPL code. Do you mean that it's illegal to provide, develop, etc samba solutions and/or custom vfs modules without providing the source code? The vendor is Hitachi. It would also be nice to provide something like "according to XXX, you are *forced* to provide your work, just in case they pretend to ignore the request. Anyway, does this confirm that finally the kernel patch is not necessary?
The GPL says that if someone (Hitachi) distributes GPL code, that must include an offer to get you the source code. If the NAS box is based on Samba, that is GPL. VFS objects link into Samba, which makes them GPL as well. So you have the right to request the source code for both the exact Samba version on that box including the VFS objects' source code. It's legal to ship it without source, but they must give it to you when you ask for it, and they must have included the hint that the product contains GPL code.
I think that an aside question has taken us out of the main point, so please let's forget the last comments and get centered again in the initial question. I currently have done some tests by adding and removing vfs_objects, and my best approach is by using vfs_objects = acl_tdb, so when creating files natively from the unix side (a plain local user or a service like apache or jboss called from some web app, but the service runs as a specific user), the acl for inheritance from the parent is lost, but this doesn't happen if the file/dir is created from windows side. Surely it's what you say about implementation of full NTFS acls in the kernel, but anyway it looks like samba does some extra work, I'd say that creating internally the extra attributed in the corresponding tdb so samba itself recognizes the attributes properly. So, as a possible workaround, can you explain what is this that samba does, and so we can walk to a solution? Any other idea, or links documenting this?
this is more a support or config issue here. Also this is quite old now, please test again with an up-to-date samba release and discuss config questions on the samba mailing list.