On Fri, 26 Jun 2020 16:56:48 +0200 "Johannes Beisswenger" <johannes.beisswen...@cetitec.com> wrote:
> The OP_CREATE/REPLACE/SET_XATTR operations in pseudo_op() don't use > msg_header.mode at all, it is only used for DB sanity checks, which > in turn only use the non-permission bits. Right, the relevant part is the immediately following wrap_chmod/wrap_fchmod. I had forgotten about this chunk of code. And... that leads us to the realization of how it is possible that this ever didn't bite us before. The historical reason this exists is that at some point, GNU tar decided that it was a crime against nature, humanity, and God to use a stable existing API when a new API existed which could do the same thing at hundreds of times the computational cost, and abandoned all use of chmod() in circumstances when extended attributes are available. But in practice, this only happens for regular filesystem modes that do not require an ACL, and allow us to replace "here's your 12 bits of values" with "here's a small binary blob you can decode expensively". But usually that's all that's present, so we just hit the path where we call chmod/fchmod and return early. For us to hit this, we have to have gotten a system.posix_acl_access message which contains access list values other than those, which of course never happens, because who would actually use ACLs for their intended purpose, instead of as a ridiculously expensive way to implement chmod? And yeah, I think you're right -- this assignment is just plain unneeded. (I think the Darwin port is long-dead because Apple's security stuff makes it a pain to work with. Basically, "can we get this working on Darwin" was a high priority and common request until about three days after I got it running, and I don't think anyone's asked about it since.) -s
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140019): https://lists.openembedded.org/g/openembedded-core/message/140019 Mute This Topic: https://lists.openembedded.org/mt/75120999/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
