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

Ralph Boehme <[email protected]> Tue, 21 Jul 2026 15:38:41 +0200
Newsgroups	org.kernel.vger.linux-cifs,org.kernel.vger.linux-kernel
Message-ID	<[email protected]>
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).

What we might want to do instead is send the namespace over the wire in 
all cases, but in a separate protocol field (expressed by splitting the 
dotted string into two words seperated by a comma):

Client        Network        Server
=============================================================
Linux:                       Linux:
user.foo      user, foo      user.foo
system.bar    system, bar    system.bar

FreeBSD:                     Linux:
*1, foo       user, foo      user.foo
*2, bar       system, bar    system.bar

*1: EXTATTR_NAMESPACE_USER
*2: EXTATTR_NAMESPACE_SYSTEM

This way we have a clear way how implementations can map their namespace 
to the protocol, and server and client know exactly what to do.

Thoughts?
-slow

> 
> The current workflow works as follows:
> 
> Client request                                 --user.EA
> ↓ CIFS client strips off the "user."
> prefix SMB EA layer receives:          --EA
> ↓ ksmbd adds back the "user."
> prefix Server filesystem layer:         --user.EA
> 
> After ksmbd finishes mapping to the underlying extended attribute name, 
> filesystem compatibility checks, value validation and all related 
> operations should be delegated uniformly to |vfs_setxattr()|. This 
> mapping logic is not meant to duplicate the full set of xattr namespaces 
> supported by the VFS. Instead, it filters which SMB extended attribute 
> names get parsed as native Linux xattr names.
> 
> I will revise the patch to enable native namespace mapping only when 
> both of the following two conditions are satisfied:
> 
>    1.The request is sent with POSIX extended attribute parameters;
>    2. The mapped server-side user account is root or an account with 
> administrative privileges.
> 
> Thanks!
> 
> 
> 在 2026/7/20 14:57, Ralph Boehme 写道:
>> On 7/17/26 5:39 AM, Ze Tan wrote:
>>> +static bool ksmbd_is_posix_ea_name(const char *name, size_t name_len)
>>> +{
>>> +    if (ksmbd_is_security_capability_ea_name(name, name_len))
>>> +        return true;
>>> +
>>> +    return false;
>>> +}
>>> +
>>> +static int ksmbd_map_ea_name_to_xattr(bool posix_extensions,
>>> +                      const char *ea_name, size_t ea_name_len,
>>> +                      char *attr_name)
>>> +{
>>> +    if (posix_extensions &&
>>> +        ksmbd_is_posix_ea_name(ea_name, ea_name_len)) {
>>
>> why the check for allowed namespaces via ksmbd_is_posix_ea_name() at 
>> all and not just pass through whatever the client sends us, pass it 
>> down and let the xattr subsystem deal with it?
>>
>> Still wrapping my head around this so I might be missing something 
>> obvious. :)
>>
>> Thanks!
>> -slow
OpenPGP_signature.asc (application/pgp-signature, 840 B)