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