Re: euidaccess

[Jim Meyering]

Bruno Haible wrote:
>> > Thanks -- I've pushed the modified patch.  Now the only license issue
>> > within gnulib is 'euidaccess'...
>
>> +    euidaccess: relax license to LGPLv2+

Hi Bruno,

> This won't help much, because 'euidaccess' depends on 'group-member', which
> depends on 'xalloc', which is GPL. 'xalloc' is GPL and not LGPL because it
> can call exit(), which is not appropriate for a library.

Thanks for point that out.
It looks like it won't be hard to fix group-member.c.
Patches welcome.

> This module uses
>   - faccessat() on glibc.
>   - EFF_ONLY_OK on IRIX, OSF/1, Interix 3.5.
>   - accessx() on AIX.
>   - eaccess() on FreeBSD.
>   - setregid if PREFER_NONREENTRANT_EUIDACCESS is defined, on MacOS X,
>     NetBSD, OpenBSD, HP-UX, Solaris, Cygwin.
>   - xmalloc() and getgroups() otherwise, in particular on mingw and BeOS.
>
> The MacOS X manual page for access() says:
>   "access() is a potential security hole and should never be used."
> Why do they say this?
> Because it uses the real uid and gid, not the effective one?
> Or because of the time window between the call and the following open() call?
> Or because it does not follows symbolic links (no O_NOFOLLOW)?

all of the above, I suspect ;-)

For some of the same reasons, the euidaccess function/module should be
avoided, simply because it cannot be used robustly -- by its very nature.
Use faccessat instead.

The only use in gnulib is via faccessat, so the group-member
problem will have to be fixed, so one of us will get to it eventually.

The only real use of euidaccess in coreutils is in remove.c,
and is in dead code now on most systems, because that function is
called only when !openat_needs_fchdir.

(the use in test.c is unwelcome, but even less important)

Actually, looking at the euidaccess* use in remove.c
I just noticed/fixed a sub-optimality.  Technically, a bug:

  http://marc.info/?l=coreutils-bug&m=126788070112398&w=2