Re: Bug#537492: menu: Binary without execution bits.
On Sat, Jul 18, 2009 at 11:30:27PM +0200, Cyril Brulebois wrote:
> Cyril Brulebois <kibi@debian.org> (18/07/2009):
> > Sven Joachim <svenjoac@gmx.de> (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
aurelien@aurel32.net http://www.aurel32.net
Reply to: