Prev: Can I use net ads join without DNS
Next: [Samba] [samba] Share authentication via AD
From: Jeremy Allison on 16 Sep 2009 13:00
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
From: Wes Deviers on 16 Sep 2009 13:40
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
From: Jeremy Allison on 16 Sep 2009 14:10
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
From: Miguel Medalha on 16 Sep 2009 15:40
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
From: Jeremy Allison on 16 Sep 2009 17:50
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
 |  Next  |  Last
Pages: 1 2
Prev: Can I use net ads join without DNS
Next: [Samba] [samba] Share authentication via AD