Re: bin/59449: which(1) / whereis(1) fails if the euid/egid != uid/gid

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59449; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/59449: which(1) / whereis(1) fails if the euid/egid != uid/gid
Date: Sat, 31 May 2025 07:39:42 +0700

 I think your fix is the wrong one, a better fix is to replace
 the call to setuid(euid) with a call to setreuid(euid, euid)
 and setgid(egid) with a call to setregid(egid, egid).  Those
 functions don't have the "only effective->real" restriction that
 seems to have been imposed (for some reason) upon set[ug]id().
 
 The man pages for those funcs (setreuid and setregid) claim that
 they're obsoleted by the (truly obnoxious) Saved ID functionality,
 but they're not, and shouldn't be, setreuid() and setregid() are
 in POSIX (in the XSI optional set, though everyone supports XSI)
 and aren't even close to obsolete (and the Saved IS stuff can only,
 and is intended to only, solve one particular issue with ID swapping).
 
 Of course, a much better fix would be to stop using access() for
 this (or almost any other) purpose - what it was designed for was
 to allow setuid (or setgid) processes check whether the real user
 (the one running the setid process) has permission to access a
 file, before blindly going ahead and opening it using its (usually)
 enhanced permissions.   It really should not be used for anything
 else, it causes all kinds of problems, including things like this
 bizarre workaround that which/whereis are doing to try and force
 access() to do what is needed.
 
 kre