I'm not sure how serious this issue is, but I think it may cause problems in some environments. The system is Linux, RedHat 7.0, Perl 5.6.0, glibc 2.2.4, latest updates. Recently I run 'lsof' on unprivileged Apache httpd process running mod_perl application and was pretty surprised to see /etc/shadow in the list of opened files. I've traced this to CGI.pm, which use getpwuid()[7]/tmp to find temporary directory. CGI.pm was preloaded by master httpd process with root privileges. I've tried some perl one-liners and found that there is a problem with getpwuid() Perl (not glibc) function: ida(/0)root:~> perl -e 'getpwuid($<); sleep 100' & [1] 27102 ida(/0)root:~> lsof -p 27102|grep shadow perl 27102 root 3r REG 80,2 1262 289062 /etc/shadow ida(/0)root:~> [1]+ Done perl -e 'getpwuid($<); sleep 100' So any (Perl, libperl.a) program, that is originally started with superuser privileges, calls getpwuid(), then drops privileges still have read-only access to /etc/shadow file. Fortunately, close-on-exec flag is set and only fork()'ed children can use file descriptor. One real example of such application is Apache with mod_perl with CGI.pm preloaded. Of course, starting Apache+mod_perl by root (even preloading standard modules only) means quite high level of trust. It is probably organization internal server, or customer dedicated server (in hosting environment), but there is no good reason to have go+r on /etc/shadow anyway. I also examined Perl 5.6.1 on Linux and 5.00503 on FreeBSD and found that these versions close shadow password database after use. arkadi.
This archive was generated by hypermail 2b30 : Mon Jul 29 2002 - 14:53:28 PDT