Hi, Just a reply to note that this isn't just an issue for glibc, but for any program that might use linux syscalls directly (with fallbacks). On Tue, 2020-11-24 at 13:54 +0100, Florian Weimer wrote: > > I agree that the standard should mandate ENOSYS, and I've just proposed > a specification change here: > > <https://groups.google.com/a/opencontainers.org/g/dev/c/8Phfq3VBxtw> > > However, such a change may take some time to implement. Thanks, that is really appreciated. We face the same issue in valgrind. > Meanwhile, we have the problem today with glibc that it wants to use the > faccessat2 system call but it can't. I've been told that it would make > glibc incompatible with the public cloud and Docker. The best solution > I could come up with it is this awkward probing sequence. (Just > checking for the zero flags argument is not sufficient because systemd > calls fchmodat with AT_SYMLINK_NOFOLLOW.) > > I do not wish to put the probing sequence into glibc (upstream or > downstream) unless it is blessed to some degree by kernel developers. I > consider it quite ugly and would prefer if more of us share the blame. > > We will face the same issue again with fchmodat2 (or fchmodat4 if that's > what it's name is going to be). For valgrind the issue is statx which we try to use before falling back to stat64, fstatat or stat (depending on architecture, not all define all of these). The problem with these fallbacks is that under some containers (libseccomp versions) they might return EPERM instead of ENOSYS. This causes really obscure errors that are really hard to diagnose. Don't you have the same issue with glibc for those architectures that don't have fstatat or 32bit arches that need 64-bit time_t? And if so, how are you working around containers possibly returning EPERM instead of ENOSYS? Thanks, Mark
