It seems like this function returns true if you try to change uid to the already active user - even if you aren't root.
Should save you one if-statement in some cases.
posix_setuid
(PHP 4, PHP 5)
posix_setuid — 現在のプロセスの UID を設定する
説明
bool posix_setuid ( int uid )現在のプロセスの実際のユーザ ID を設定します。 この関数は特権関数であり、実行するにはシステム上において適当な権限 (通常は root) が必要です。
パラメータ
- uid
ユーザ ID。
返り値
成功した場合に TRUE を、失敗した場合に FALSE を返します。
参考
| posix_setgid() |
posix_setuid
hpaul/at/abo/dot/fi
30-Jul-2006 03:56
30-Jul-2006 03:56
rjmooney at syr dot edu
09-Nov-2003 08:40
09-Nov-2003 08:40
For simple operations, you can easily create a privilege-separation mechanism to perform commands that require elevated privileges.
For example, in creating a document repository, I had the need to provide access to certain directory and file operations based on a user's login name. It's unrealistic and unsecure to provide the web server access to all of the directories that the user may need to access, so I created a setuid() script to perform the required operations for me.
An exerpt from the code demonstrates this:
<?
//
// main.php
//
// Perform a privileged stat()
function privsep_stat($path)
{
// Call the privilege separation program, ask for a stat of the specified path
$serialized_result = exec("/path/to/privsep.php stat " . $path, $oa, $return_code);
if ($return_code != 0)
{
return false;
}
// Return the unserialized object
return unserialize($serialized_result);
}
// Get file statistics on a file we don't have access to as the web server user
$st = privsep_stat("/private_directory/private_file");
print_r($st);
?>
privsep.php looks like this:
#!/usr/local/bin/php
<?
//
// privsep.php
//
// Don't allow this script to be run from the web
if (isset($_SERVER['REQUEST_METHOD']))
{
print "<br>This program is not intended to be run directly from the WWW.\n";
return 1;
}
// TODO: add your argument validation here
// A stat was requested
if ($argv[1] == "stat")
{
// Reset the stat() cache
clearstatcache();
// Original user ID
$original_uid = posix_get_uid();
// Set our real user ID to root
$success = posix_setuid(0);
if (!$success)
{
print "Error: Cannot setuid().\n";
return 1;
}
// Store the file statistics
$st = stat($argv[2]);
// Drop the real UID back to the calling user ID
$success = posix_setuid($original_uid);
if (!$success)
{
print "Error: Cannot setuid().\n";
return 1;
}
// Drop the effective UID as well
$success = posix_seteuid($original_uid);
if (!$success)
{
print "Error: Cannot seteuid().\n";
return 1;
}
// Serialize the result and print it
$result = serialize($st);
print $result;
// Success!
return 0;
}
?>
Finally, privsep.php's permissions are configured like this:
# chown root:wheel privsep.php
# chmod 4755 privsep.php
And look like this:
-rwsr-xr-x 1 root wheel 1000 Nov 1 00:00 privsep.php
It's probably wise to keep privsep.php out of your document root to help mitigate any successful attack.
This method can be extended for other functions. Use at your own risk.
simon at dont-spam-me-pleease dot simonster dot com
03-Aug-2002 07:53
03-Aug-2002 07:53
Here's some Perl code to run a PHP script setuid. Just put it into a CGI, make that CGI setuid and executable, then call the CGI where you would usually call the PHP script.
#!/usr/local/bin/perl
# Perl wrapper to execute a PHP script setuid
# 2002 Simon Kornblith
# Requires PHP CGI
# Make UID = EUID (so that PHP can run system()s and execs() setuid)
$< = $>;
# Set this to the path, so that we can't get poisoned
$ENV{'PATH'} = "/home/httpd/cgi-bin/ssl/admin";
# Open the PHP script (must start with !#/usr/local/bin/php or similar and
# be executable
open(STDOUT, "| /home/httpd/cgi-bin/ssl/admin/new.php");
# Write STDIN to PHP script
print while <STDIN>;