On 9/18/2018 7:44 AM, Frank Steiner via rsync wrote:
Hi,
the man page states
For systems that support extended-attribute namespaces, a copy being
done by a super-user copies all namespaces except system.*.
That's the reason why NFAv4 ACLs are not copied as they are in the
system.nfs4_acl (or system.nfs4acl) namespace.
Why are those namespaces excluded?
Not being able rsync ACLs von NFSv4 is a major drawback now that
NFsv4 becomes standard oder v3 and ACLs are getting more widely used.
----
Because they are storing them in the security (sometimes also
called system) section and not the 'root' section (at least on XFS).
The linux kernel disallows you reading ex-attrs with the Security
label.
I don't particularly like it for the same reasons you don't.
It takes patching a linux kernel to enable them being copied. I've
done it but more as proof of theory. Problem comes in when you restore
attribute to a secure namespace. Are those attrs really secure when you
take them "off the system". If not, you could modify them, then if
they are copied to a target, you could use modified attrs to
give yourself root capabilities.
So...have to solve that before it can be safely allowed.
NeverTheLess, it's still a potential hole to allow copying of such
security attrs. Unless you want to change the way security attrs are
stored to use 4k-long signing strings to ensure non-tampering, I don't
see how you can do it...and doing that would be adding 4k to each
attribute...UG!
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
