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

Ralph Boehme <[email protected]> Tue, 21 Jul 2026 19:10:25 +0200
Newsgroups org.kernel.vger.linux-cifs,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 7/21/26 6:41 PM, Steve French wrote:
> On Tue, Jul 21, 2026 at 8:48 AM Ralph Boehme <[email protected]> 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.
OpenPGP_signature.asc (application/pgp-signature, 840 B)
-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEE+uLGCIokJSBRxVnkqh6bcSY5nkYFAmpfqAEFAwAAAAAACgkQqh6bcSY5nkYi
ng/+KTttnH4Jfn73vN4L35NSy22In8prin1I4LNDMSzQnEyGhEIW4RbEotqB6RxSTaCaGJRyqvRV
u3QUTA9VPp5HM37aumtMd+Tv8K8K6HjBj/BA3a4TVXF9e8dA33f/DywpkD7kh35T+TlXOL2hZ9IA
5j/0t2R3Ja1M/vWbR8pZhl4VDhQcdTrED5I2Z8YzBsBjRespvXBuAU8Xgt/YNix8yCHbuXfRi91u
BI6ukaQsQKTW3awu1y57tgvZ0rvzXUC37qxAmhB4p07dYXUAiJ5FjTxTLK5qkHdsMAGk2MAxiPQy
PWDYNQZgLizNFf1atT725TzDtZpPksgv0mHtRnG0bJMXHpv6M3fZjKbKyNWMipbOhPxDqdI2QtcV
STLOZiS0/WDrEQ1K3ZW0lwLPNV1kf1Qy9zLZfUNnEamZ7TTcq5inefnYdSWHaZlA/+Khrg5rMHBp
lJeoAozAr/8TeBXMuUOuAcmr5Yn+9uQCPEsw+dkzs9qKH9JZD1pLcTZaSRTQ5ghHBcrE4SE1GWps
A4yibnRLRA+Tlxitvai6i3JDDiJvdko1oPOE31dYIHnPShVYSiwIP8MyNP/UhPz+czcpUDQp5qh1
cp+kxa7mqSf6Pv6pb+xBaVTLBe7/ooGDuJGfQQ+3d8vnT3hHgFtS3g2Ifr5JES6nEh0mA2BGstMB
MN4=
=ROVZ
-----END PGP SIGNATURE-----