Prev: Can I use net ads join without DNS
Next: [Samba] [samba] Share authentication via AD
From: Miguel Medalha on 16 Sep 2009 19:40

>> 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
From: Wes Deviers on 17 Sep 2009 10:30
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
From: Jeremy Allison on 17 Sep 2009 12:00
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
From: Miguel Medalha on 18 Sep 2009 17:20
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
From: Wes Deviers on 18 Sep 2009 18:10
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
First  |  Prev  | 
Pages: 1 2
Prev: Can I use net ads join without DNS
Next: [Samba] [samba] Share authentication via AD