[Samba] ACL misbehavior moving from POSIX ACL -> acl_xattr
Wes Deviers
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?
Thanks!
Wes
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Jeremy Allison
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
Wes Deviers
> On Wed, Sep 16, 2009 at 11:18:58AM -0400, Wes Deviers wrote:
> >
> > 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
Jeremy Allison
>
> 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.
Miguel Medalha
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
Jeremy Allison
>
> 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.
Miguel Medalha
>> 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
Wes Deviers
>
> 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
Jeremy Allison
>
>>> 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.
Miguel Medalha
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
Wes Deviers
> Please pardon me if I insist, but I am doing it with the interest of the
> community in mind, not just bitching about it.
>
>
>
> 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