🚀 go-pugleaf

>Making fingerd setuid to some 'innocent' user won't help.
>
>The man page for execve states: If a program is setuid to a non-super-user,
>but is executed when the real uid is 'root', then the program has the
>powers of a super-user as well.

The caveat is somewhat confusing.  I presume what it's trying to say is
that the program has *some* of the powers of a super-user and can, if it
chooses, obtain more of them.  A few places in the kernel check either for
effective *or* real UID being 0 (I don't remember which ones, offhand),
and if the real UID is 0 the program can set its effective UID to match
its real UID and thus get super-user privileges.

Either that, or it's describing a state of affairs that was true in older
versions of UNIX, but that is neither true in 4.xBSD nor System V, and
thus not true in many (most?) of the UNIXes around today.  Back in V7, if
the super-user ran a set-UID program, the process running the program was
not made set-UID; this is not the case in more modern UNIXes - the process
is made set-UID just as if a user other than the super-user ran it.

In any case, if you have a program that is set-UID to some user ID that
does not have permission to read some file X, and the super-user runs that
program, the program will not be able to open file X for reading unless it
sets its effective UID to match its real UID (i.e., root).  I tried this
on a 4.0 system with a set-UID "cat" (which doesn't set its effective UID
to match its real UID), and it is indeed true.

[[ This was sent in later:  --wnl ]]

More precisely, the man page states (in the SunOS 4.0 and 4.3-tahoe
manual) that the program has *some* of the powers of a super-user.  This
is, as I mentioned, true, but the powers in question do not include the
power to read arbitrary files.