On Mon, Feb 1, 2021 at 8:06 PM Rob Landley <[email protected]> wrote: > On 2/1/21 9:53 PM, Yi-yo Chiang wrote: > > There has to be a reason, but I'll defer that question to Elliott.. > > > https://cs.android.com/android/platform/superproject/+/master:bionic/libc/bionic/faccessat.cpp;l=46;drc=50080a29f7327fcd009344844bb9e643b2d6b9c3 > > > > This line also left me scratching my head for half a day. > > At a guess, that first explanatory URL in the comment should be: > > https://www.openwall.com/lists/musl/2015/02/05/2
yeah, sadly nnk is no longer at google so i can't drag him in to the conversation. the good news though is that i've had a tab open since April 2020 to remind me to take advantage of faccessat2(2) on kernels that have it. i'll send that patch out shortly[1]. i still don't intend to try to fake AT_EACCESS or AT_SYMLINK_NOFOLLOW on old kernels though. we've tried to avoid that kind of thing in general. (because if it were possible to do it perfectly in libc, there wouldn't have been a new system call added, and we've erred on the side of "we're going to tell you quite clearly with EINVAL that you can't have this, rather than do a 'best effort' implementation that may or may not be good enough for your purposes, because we don't know what those purposes are".) tbh, that's also a reason not to use faccessat2(2) until it's guaranteed to be available, but since GKI devices [ https://source.android.com/devices/architecture/kernel/generic-kernel-image#gki2_0-products] will be > 5.8 anyway, maybe that calculus will change in future... ____ 1. https://android-review.googlesource.com/c/platform/bionic/+/1573339 > Rob > _______________________________________________ > Toybox mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
