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

[Steve French]

On Tue, Jul 21, 2026 at 8:48 AM Ralph Boehme <slow@xxxxxxxxx> 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. It
shouldn't regress existing servers and clients who are sending "foo"
across the network (without the prefix) for the most common EAs


> 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
>


-- 
Thanks,

Steve