On Fri, 2020-06-26 at 10:36 -0500, Seebs wrote: > On Fri, 26 Jun 2020 16:56:48 +0200 > "Johannes Beisswenger" <[email protected]> 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.)
I need to do something about the patches queued up for pseudo. I'm going to put them all on an "oe-core" branch in the pseudo repository so we at least have a common place to use them from and get the recipe cleaned up until such times as we can get proper review/merge to master. That shouldn't cause any problems and lets us improve things a bit. There is one patch I'm not going to put there as looking at it, I suspect it needs reworking and really isn't upstreamable, I think the rest are appropriate given OE is one of pseudo's main users and can hence influence its development. Hope that is ok with you seebs! Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140026): https://lists.openembedded.org/g/openembedded-core/message/140026 Mute This Topic: https://lists.openembedded.org/mt/75120999/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
