Created attachment 2109 [details] Patch that implements xattr in sftp-server In the attachment you will find a patch that implements xattr functionality in the sftp-server, intended to be used by sshfs. A corresponding patch to sshfs will be filed to the sshfs developers. I did not implement xattr in sftp-client, because I think that it is not really useful: For sshfs, the low level functions set-/get-/list-/removexattr are needed. But for a user interface like sftp-client, high level functions like set-/getfacl and set-/getfattr would be necessary. These are rather complex and would unnecessarily burden the sftp-client code in my opinion. Additionally, I changed the limitation of entries per message in process_readdir from max. 100 entries to a packet size limitation, because the size per entry may be enlarged by xattr data. But typically, much more than 100 entries can now be sent in one message. I hope, that you are interested in my patch. Thanks, Eberhard
I'm not sure we want to go beyond basic POSIX in our sftp. Keeping it simple was one of the motivations for not implementing features from draft-filexfer versions > 2
Hi Daimen. I think we recently had a small talk in some other enhancement I've requested (interactiveness of scp), where you said scp can't easily enhanced... but such things should be doable with sftp. May I therefore draw your attention on this again? I think XATTR/ACL support is really really important and would be great to see in OpenSSH. Actually the only feature I recall right now, that I'd anticipate even more is #1926. Especially sshfs would benefit greatly from ACL/XATTR support in openssh. I know people often turn down ACLs/XATTRs because they consider them not widely used/supported... but that attitude is mainly the reason why this doesn't change. So hopefully this will accepted in ssh :-) Cheers, Chris.
Does anyone know whether anything is going on with SFTP (especially also with repsect to ACLs and XATTRs)? More than a year ago we saw this http://tools.ietf.org/html/draft-moonesamy-secsh-filexfer-00 which apparently tried to restart the draft-ietf-secsh-filexfer series... Not having ACLs/XATTRs in SSH/SFTP continues to be a pain in the arse, especially since basically all the bigger UNIX/Linus filesystems support them and there is a slowly but constantly growing number of users.
Just adding that the lack of ACLs/XATTRs in SSH/SFTP is indeed a pain in the arse!
I agree with others: xattr support would be very good. I'm working on a FUSE fs using libssh2, and the filesystem would benefit a lot when xattr are supported. Why the patch is not accepted? Maybe there is a reason apart from "Keeping it simple was one of the motivations for not implementing features from draft-filexfer versions > 2". Xattr support is already supported by Linxu for years, and is not hard to implement. It's just a simple get/set mechanism. So I'm very pro for adding this feature. Please reconsider the possibility to add this. Stef Bon the Netherlands
Instead of using custom SFTP extensions for xattr functionality, another approach you might consider, protocol-wise, is the use of the SSH_FILEXFER_ATTR_EXTENDED flag of the ATTRS structure, which is part of SFTP protocol version 3 (and earlier); see: https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-5 SFTP clients can send xattrs as ATTR_EXTENDED key/value pairs in SETSTAT/FSETSTAT requests; OpenSSH should send the xattrs in READDIR and STAT et al requests the same way. This would still require patching OpenSSH's SFTP server to use the platform-specific extended attribute APIs (extattr(9) for BSDs, xattr(8) for Linux, with Mac providing something similar to Linux but with different function signatures). It would also leave open the question of how an SFTP client could _remove_ an extended attribute from a file; the Draft for SFTP does not provide a way of doing so. One MIGHT argue for a SETSTAT request that contains an attribute name with an empty value as a signal that that extended attribute should be deleted. With the above approach, xattr support might benefit more existing clients (and servers) than the approach using custom OpenSSH-specific extensions.
We don't have any desire to implement xattr support in sftp, sorry. If you need it, you might want to consider an alternate sftp-server.
What a pity... it seemed to be something quite useful for many cases. AFAIU, the only reason not to support it was staying at the base level of the sftp "standard"... however, OpenSSH goes in so many places way beyond the standards...
Especially since Eberhard's patch doesn't them *that* intrusive to other parts of openssh, wouldn't simply be possible to use something like RFC 2389,... so server and client could negotiate whether things beyond the basic features are supported and XATTRs support would only be enabled then... that should at least solve most compatibility worries.
Close all resolved bugs after 7.3p1 release
Yes I know that this has already been rejected ;-) ... but under the light of scp now getting SFTP under the hood... is there any willingness from upstream side to reconsider this? With SFTP being much easier extensible, scp could eventually become a true/full cp, ... by supporting stuff that's currently ignored (like here the XATTRs and thus ACLs)... and maybe in the future even file owners (of course only with the respective capabilities and if there is a mapping of names).