Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
Please pardon me if I insist, but I am doing it with the interest of the community in mind, not just bitching about it. I understand that if you address the problem of full compatibility with Windows ACLs you risk to break compatibility with other clients, such as NFS clients. Yet, in numerous cases Samba provides services to Windows clients only. Many people will use a Linux server to provide services to a network of Windows clients. This is very common. Even Linux clients can use CIFS to connect. This is why it seems to me that an optional special behavior of samba, maybe through a VFS module, would be highly adequate to address this problem. Remember, the NTACL vfs module calls down to a lower layer module to set the mapped acl onto the underlying filesystem. Without a null ACL module you'll get the following problem: If you don't have posix acls on the filesystem how do you map an incoming ACL containing two or more users or groups ? Please consider the following: - The underlying file system would need no ACLs and all files would be owned *by a special user* possessing common ugw 777/666 rights over them. - A special VFS module would then receive all requests from clients. All permissions and user/group rights would be taken care of by the VFS module and stored as extended attributes (I am assuming, of course that the storage space provided to extended attributes by the filesystem is big enough for that purpose. If not, could another storage method be envisioned?). Clients would never communicate directly with the underlying filesystem, all operations would be conducted by means of the VFS layer. - This VFS module would be turned on by a smb.conf entry and the options for the VFS module would also allow a system administrator to chose a name of his for that special user, in order to make it unique and different from all other systems out there. - Even if none of the current VFS modules is capable of the described behavior, it seems to me that it would be VERY advantageous to produce a new one for the certainly very numerous users needing the described functionality. Only users needing it would use the proper VFS module, to the others the current status would remain unchanged. I really don't see why this could not be implemented. Perhaps it goes somewhat against established thinking but it really seems possible to me. NOTE: Perhaps we wouldn't even need a VFS module, only a smb.conf parameter to switch the behavior of the samba daemon? Please note: all disk operations would be done in the name of that special user, using full permissions. Ownership and rights would then be filtered by the adequate layer to be seen by clients in the appropriate way. Best regards Miguel -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
On Friday 18 September 2009 02:06:41 pm Miguel Medalha wrote: Please pardon me if I insist, but I am doing it with the interest of the community in mind, not just bitching about it. I really don't see why this could not be implemented. Perhaps it goes somewhat against established thinking but it really seems possible to me. NOTE: Perhaps we wouldn't even need a VFS module, only a smb.conf parameter to switch the behavior of the samba daemon? Please note: all disk operations would be done in the name of that special user, using full permissions. Ownership and rights would then be filtered by the adequate layer to be seen by clients in the appropriate way. Best regards Miguel Miguel (and others..) I've been dinking around with implementing this in my spare time, using the existing 3.3 VFS ACL_xattr module as a guide. I *think* the number of modifications to get it to work that way are pretty minor, actually. Of course, I could be completely wrong because my C is very rusty and I'm not all that familiar with the Samba source code. Jeremy's idea is pretty straightforward; if you just discard any filesystem- level ACL operations, the existing xattr code should still work. Then, you can do some share definitions to force user group ownership of everything, and hopefully walk away. If somebody who's better at it wants to work on the problem, that would be awesome, because I have little confidence in my own. But I'll keep at it and see what happens. Wes -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
On Wednesday 16 September 2009 06:01:21 pm Miguel Medalha wrote: I am ignorant enough on these low-level matters. I almost understand your statement. But... consider the following: - At the filesystem level ALL the permissions are 666 or 777 - The above are ONLY seen by the VFS layer, not by the client side - The VFS module writes the real ACLs as extended attributes only (or some other method), always setting them as 666/777 at the filesystem level - Clients only see the ACLs provided to them *by the VFS layer* and never directly from the filesystem Wouldn't this provide any desired type of ACLs? What am I missing here? Thank you That's the direction I'm heading experimentally; there are a few shortcomings that I can think of right away, but they can be mitigated (and the upside is big from a usability standpoint, I think) - If there's a flaw discovered in Samba that takes place in non-root code, the filesystem level ACLs will still prevent information disclosure. If you turn over all ACL validation to Samba and that validation is what can be bypassed, then you've lost a layer of protection. - POSIX ACLs mean that you can set permissions from Windows and those permissions will be also affect non-Samba services (FTP and such). In lots of installations that's probably nice to have, but for a dedicated file server where the only user interface is Samba, it wouldn't matter. - How to apply actions might be odd; Traverse Folders is pretty self- explanatory and is easy to manage in the virtual ACL database. Take Ownership is slightly harder: if you take ownership of a set of files, does that imply fake ownership in just ACLs, or real ownership at the POSIX layer? If Take Ownership doesn't change the UNIX owner, it means that any action on a file owned by POSIX user A but owned by NTACL user Z would have to be run as root. Adding more root operations is generally considered Bad. A bit farther on, and the logical next step, then, is that you don't actually need matching POSIX accounts anymore, By the time you've implemented the VFS ACL the way you and I were thinking (and trust that it's secure) you can just run the entire Samba infrastructure as UID = samba, and let the VFS ACL layer take care of all access control. Every file on the server is now owned by POSIX user samba, libnss-ldap is no longer necessary Of course, that idea has been debated thoroughly both on mailing lists and anywhere two Samba users meet on the street, so I'm not touching it : ) Is that along the lines you were thinking, or did I totally miss? Best, Wes -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
On Wed, Sep 16, 2009 at 11:01:21PM +0100, Miguel Medalha wrote: All files/dirs are 666 or 777. According to my reading, since there are no POSIX extended ACLs, if the VFS layer passes an access, then it only should be compared against the standard UGO permissions. That's correct - but the problem isn't access, it's when the incoming ACL is set onto the underlying filesystem. Most ACLs can't be mapped onto ugw permissions. As I said, you need a vfs_acl_null module that will drop any set call, and will return Everyone:Full control on read. I am ignorant enough on these low-level matters. I almost understand your statement. But... consider the following: - At the filesystem level ALL the permissions are 666 or 777 - The above are ONLY seen by the VFS layer, not by the client side - The VFS module writes the real ACLs as extended attributes only (or some other method), always setting them as 666/777 at the filesystem level - Clients only see the ACLs provided to them *by the VFS layer* and never directly from the filesystem Wouldn't this provide any desired type of ACLs? What am I missing here? Remember, the NTACL vfs module calls down to a lower layer module to set the mapped acl onto the underlying filesystem. Without a null ACL module you'll get the following problem: If you don't have posix acls on the filesystem how do you map an incoming ACL containing two or more users or groups ? Can't be done without an underlying ACL implementation. The mapping code will fail and RETURN AN ERROR. Then the underlying ACL set will fail, so the entire operation will fail. That is what you are missing. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
On Wed, Sep 16, 2009 at 11:18:58AM -0400, Wes Deviers wrote: List, I had Samba 3.0 running on Debian Lenny configured to use POSIX ACLs on ext3. They worked fine, or at least as fine as NT - POSIX mapping ever did. After testing 3.3 with acl_xattr on using a different machine, I decided to give it a whirl on the production server. And yes, I know it's experimental. I defined a share thusly: vfs objects = acl_xatt acl map full control = true inherit acls = yes map acl inherit = yes map read only = Permissions nt acl support = yes acl group control = true dos filemode = yes enable privileges = yes store dos attributes = yes This is identical to the setup on the test machine, which worked correctly. On the production machine, trying to set ACLs via XP's Explorer interface fails with a permission denied. The log: set_canon_ace_list: sys_acl_set_file type file failed for file TestDirectory/Test (Operation not supported). Having both POSIX ACL and the VFS object turned on produced some interest results, so last night I unmounted /samba, turned off -o acl, and remounted it. It now has user_xattr turned on, but -o acl is *off*. Restarted Samba, everything seemed to work. In the harsh light of users' morning, it appears that Samba is still trying to use the POSIX ACL layer to store ACLs, although that's a best guess based on the error message. How can I insist that Samba use the vfs object ACL module, instead of the POSIX acls? You can't at the moment. Samba still requires the incoming ACL to be converted into an underlying file system ACL, as the underlying filesystem still must have the final decision on access decisions. The NT acl is stored as an extra layer of ACL metadata on top of this, which is also consulted. You could slot in a null ACL module underneath the acl_xattr layer that always allowed acl set and returned an allow everyone acl on read, but that isn't coded yet (shouldn't be too hard though). Currently if you want native NT ACLs only I suggest you use the NFSv4 module, which is pretty close to native Windows ACLs. Jeremy -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
On Wednesday 16 September 2009 12:56:11 pm Jeremy Allison wrote: On Wed, Sep 16, 2009 at 11:18:58AM -0400, Wes Deviers wrote: SNIP How can I insist that Samba use the vfs object ACL module, instead of the POSIX acls? You can't at the moment. Samba still requires the incoming ACL to be converted into an underlying file system ACL, as the underlying filesystem still must have the final decision on access decisions. The NT acl is stored as an extra layer of ACL metadata on top of this, which is also consulted. You could slot in a null ACL module underneath the acl_xattr layer that always allowed acl set and returned an allow everyone acl on read, but that isn't coded yet (shouldn't be too hard though). Currently if you want native NT ACLs only I suggest you use the NFSv4 module, which is pretty close to native Windows ACLs. Jeremy Jeremy, As always, thank you for your reply! I'm confused now. I have a VirtualBox instance set up identically, except that the underlying filesystem (ext3) has never had -o acl set on it, only -o user_xattr. What I've been doing, which is dangerous but effective, is setting file creation mode to 666 and letting the Samba VFS ACL layer take care of everything. That's worked. As I understood the system under the new VFS module, Samba does its internal ACL checks and if those pass, it then attempts file operations as normal, which may or may not work depending on the real file permissions. If I have POSIX ACLs applied, those also have to agree; otherwise, the normal UGO permissions are what must work. I'm clear through this part. Where I'm confused is that on a machine that I do have working, there is no POSIX ACL support, but the Samba VFS layer works brilliantly. Inheritance, take ownership, everything works on the VFS layer without needing any POSIX ACLs. On the old server, I've taken a machine that was previously storing the Samba ACL metadata as POSIX mappings, pulled the POSIX mappings out from under it, and tried to get it to use the VFS module exclusively. All files/dirs are 666 or 777. According to my reading, since there are no POSIX extended ACLs, if the VFS layer passes an access, then it only should be compared against the standard UGO permissions. Testing on a virtual machine seemed to confirm this. I think you read my question as: Why am I denied access because of my POSIX ACLs, even though the VFS ACL module is in place? I'm clear on what's involved there, I think. What I was *trying* to make my question: Since I've turned POSIX ACLs *off* at the filesystem layer by removing the ACL mount option, why does Samba continue to want to store it's ACL metadata in the POSIX ACL layer instead of the VFS module? So, no Linux ACLs, and a+rwx on all files/directories. It works on one machine : ( Or, alternately, Does Samba, with vfs object = acl_xattr, store ACLs both as a user_xattr AND an ext3 ACL at the same time? My limited testing shows that *not* to be the case, but I'm certainly not the expert. Thanks again! Wes -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
On Wed, Sep 16, 2009 at 01:38:13PM -0400, Wes Deviers wrote: Or, alternately, Does Samba, with vfs object = acl_xattr, store ACLs both as a user_xattr AND an ext3 ACL at the same time? My limited testing shows that *not* to be the case, but I'm certainly not the expert. Yes it does (store ACLs both as a user_xattr AND an ext3 ACL at the same time). It's designed that way. You might be getting away with the use cases you're trying, but it won't work long term. If you want the underlying filesystem to ignore ACLs you'll need to write a module that does this (and doesn't pass down the ACL requests to the underlying file system). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
Dear Jeremy Since I once thought about doing the same, I would like to know your views on the method that Wes describes. I quote: » What I've been doing, which is dangerous but effective, is setting file creation mode to 666 and letting the Samba VFS ACL layer take care of everything. That's worked. « » All files/dirs are 666 or 777. According to my reading, since there are no POSIX extended ACLs, if the VFS layer passes an access, then it only should be compared against the standard UGO permissions. « Thank you -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
On Wed, Sep 16, 2009 at 07:20:11PM +0100, Miguel Medalha wrote: All files/dirs are 666 or 777. According to my reading, since there are no POSIX extended ACLs, if the VFS layer passes an access, then it only should be compared against the standard UGO permissions. That's correct - but the problem isn't access, it's when the incoming ACL is set onto the underlying filesystem. Most ACLs can't be mapped onto ugw permissions. As I said, you need a vfs_acl_null module that will drop any set call, and will return Everyone:Full control on read. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ACL misbehavior moving from POSIX ACL - acl_xattr
All files/dirs are 666 or 777. According to my reading, since there are no POSIX extended ACLs, if the VFS layer passes an access, then it only should be compared against the standard UGO permissions. That's correct - but the problem isn't access, it's when the incoming ACL is set onto the underlying filesystem. Most ACLs can't be mapped onto ugw permissions. As I said, you need a vfs_acl_null module that will drop any set call, and will return Everyone:Full control on read. I am ignorant enough on these low-level matters. I almost understand your statement. But... consider the following: - At the filesystem level ALL the permissions are 666 or 777 - The above are ONLY seen by the VFS layer, not by the client side - The VFS module writes the real ACLs as extended attributes only (or some other method), always setting them as 666/777 at the filesystem level - Clients only see the ACLs provided to them *by the VFS layer* and never directly from the filesystem Wouldn't this provide any desired type of ACLs? What am I missing here? Thank you -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
