On Wed, 18 Jan 2006, J. Milgram wrote:
Also, can someone explain this comment in the "mount" man page?
nosuid Do not allow set-user-identifier or set-
group-identifier bits to take effect. (This
seems safe, but is in fact rather unsafe if
you have suidperl(1) installed.)
I poked around a bit, and it seems what happens is this:
There (used to be??) an inherent insecurity in suid scripts. As a
workaround, some systems disabled the effect of the suid bit for scripts.
suidperl was a workaround for that, in that if perl was compiled with the
suidperl option, the perl binary would try to detect when a script was
being run in a non-suid perl binary, but the scriptfile had the suid bit
set. In this case, perl would invoke suidperl (a suid perl binary) on the
script, and suidperl would grant the script appropriate permissions. This
was kind-of like re-opening the whole suid-script hole back up, but only
for perl scripts, and this is what mount(8) is complaining about. In the
presence of nosuid, suidperl would actually defeat the purpose of this
mount option for perl scripts.
Now, the wierd thing is that perlsec(1), which tells us all these
wonderful things, implies that the suid script problem was fixed in recent
kernels by leaving the script open while execing the interpreter, and
giving the interpreter /dev/fd/whatever as the script name, which is
smething I haven't been able to verify... on my Debian/testing box, suid
scripts are disabled, and the script name is not passed as /dev/fd/x, so
I'm a little confused as to what "fixed" systems perlsec(1) is referring
to (some BSD maybe?) Anyway, suidperl is part of the optional perl-suid
package, so its potential insecureness isn't installed by default.
Alexey
