[PATCH] vfs module for VxFS
realrichardsharpe at gmail.com
Tue Sep 2 18:16:23 MDT 2014
On Tue, Sep 2, 2014 at 3:36 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> On Tue, 2014-09-02 at 07:32 -0700, Richard Sharpe wrote:
>> On Mon, Sep 1, 2014 at 9:24 PM, Andrew Bartlett <abartlet at samba.org> wrote:
>> > On Mon, 2014-09-01 at 18:44 -0700, Jeremy Allison wrote:
>> >> On Tue, Sep 02, 2014 at 11:52:49AM +1200, Andrew Bartlett wrote:
>> >> >
>> >> > The concern I have is that Samba can permit access to extended
>> >> > attributes directly. You have to ban them in samba_private_attr_name()
>> >> > in source3/smbd/trans2.c.
>> There is another issue here as well, which is that Samba is not
>> flexible enough, IMO, in those cases where the OS or the FS does not
>> support separate SYSTEM and USER name spaces.
>> Then, all the xattrs have to be collapsed into one name space.
>> A trick I have used before is to prefix SAMBA xattrs with something
>> like .samba: but that requires more flexibility in the filtering.
> Samba uses the different namespaces because they have different security
> properties, which is the point I've been trying to make here. We
> certainly could use the user namespace, but the only way we could do so
> with confidence in the security of the outcome (in the general case) is
> to digitally sign all our 'system' extended attributes.
Perhaps I did not make myself clear.
There is at least one OS/FS combination that does not have a separate
SECURITY namespace. FreeBSD and ZFS, at least for 8.x and maybe going
forward. So, they all have to be mapped to the USER namespace.
I don't know if that has changed in FBSD 10, or is planned in 11.
More information about the samba-technical