Re: Bug#537492: menu: Binary without execution bits.
On Sat, Jul 18, 2009 at 11:30:27PM +0200, Cyril Brulebois wrote:
> Cyril Brulebois <firstname.lastname@example.org> (18/07/2009):
> > Sven Joachim <email@example.com> (18/07/2009):
> > > This looks strange, it seems that the test found update-menus
> > > executable, but it no longer is. Namely, the shell has apparently
> > > hashed it, since otherwise you would "update-menus: command not found"
> > > instead of "permission denied".
> > >
> > > This may be because the dpkg trigger for update-menus had been
> > > activated. Can you examine your dpkg.log entries of the failed
> > > upgrade?
> > (No sign of triggers, it's just that emacs21 gets configured before
> > menu.)
> > That one might be arch-related:
> > | kbsd:/home/kibi# which update-menus
> > | /usr/bin/update-menus
> > | kbsd:/home/kibi# ls -l /usr/bin/update-menus
> > | -rw-r--r-- 1 root root 113028 jun 8 13:13 /usr/bin/update-menus
> > That's on GNU/kFreeBSD. I still have to investigate why, but it looks
> > like if [ -x /usr/bin/update-menus ] returns true even with the
> > above-mentioned conditions. Cc'ing -bsd.
> I guess the answer is in coreutils's lib/euidaccess.c; it'd be nice if
> someone could have a look at it.
Actually this file is not used, euidaccess() from the GNU libc is used.
It calls in turn access() which is mapped to the syscall. And here comes
the portability issue:
| If the calling process has appropriate privileges (i.e., is
| superuser), POSIX.1-2001 permits implementation to indicate success
| for an X_OK check even if none of the execute file permission bits
| are set. Linux does not do this.
OTOH POSIX 2008 says:
| New implementations are discouraged from returning X_OK unless at least
| one execution permission bit is set.
Maybe we should fix that in our glibc?
Aurelien Jarno GPG: 1024D/F1BCDB73