Re: [RFC PATCH v2 6/9] ksmbd: support security.capability EAs

[Ralph Boehme <slow@samba.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1894 bytes --]

On 7/21/26 6:41 PM, Steve French wrote:
> On Tue, Jul 21, 2026 at 8:48 AM Ralph Boehme <slow@samba.org> wrote:
>>
>> On 7/20/26 3:06 PM, tanze wrote:
>>> Thanks for your question. When the CIFS client accesses user.EA, the
>>> name transmitted over the SMB protocol is simply EA instead of user.EA.
>>> ksmbd then prepends user. to convert it back to user.EA. If we pass
>>> every attribute name directly to the VFS unmodified, other types of
>>> extended attributes will return -EOPNOTSUPP due to missing handlers.
>>
>> yup, but I guess that's exactly what we want.
>>
>> If I get that right your proposal is
>>
>> Client        Network       Server
>> -------------------------------------------------
>> user.foo      foo           user.foo
>> system.bar    system.bar    system.bar
>>
>> This seems wrong (user namespace not prefixed, others prefixed).
> 
> This approach at least doesn't require changing the protocol.

By definition we're defining an SMB3 POSIX protocol here, so I think we 
should strive for a protocol that is consistent rather than encoding 
historic Linux-specific implementation details.

In the proposal above, user.* is treated differently from every other 
namespace:

user.foo    -> foo
system.bar  -> system.bar

That means the wire format no longer has a uniform representation of an 
extended attribute. Whether a namespace is transmitted depends on which 
namespace it is, which makes the protocol less self-describing and 
introduces a special case that every implementation has to know about.

This is horrible.

If the protocol instead carries namespace and attribute name as separate 
fields, every namespace is represented uniformly. Linux, FreeBSD, and 
any future implementation simply map their local namespace 
representation to the protocol, rather than the protocol inheriting 
Linux's conventions.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]