New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing POSIX::getuid/getgid and related ops #6977
Comments
From stas@stason.orgJörg Walter was helping me over irc to debug some POSIX uid/gid All the following tests are run as root. We will attempt to drwx------ root root so it should fail to do that. Test 1: Using perl's % perl -le ' \ as expected user 'nobody' can't -r, -w, -x '/root'. Notice that set Test 2: Do the same this time using the equivalent POSIX calls: % perl -le 'require POSIX; \ oops, has setgid failed? Not really, see the next test Test 3: Now don't check whether set[ug]id has failed: % perl -le 'require POSIX; \ Something is wrong as user 'nobody' should get 'NOK' (it can't read The first problem is that POSIX::getuid and POSIX::getgid return wrong % perl -le 'require POSIX; \ meaning that POSIX::set[ug]id do affect the program environment, but Now look again at the test #3, it has reported OK, even though the % perl -le 'require POSIX; \ which shows what? That directives -r, -w, -x still think that the So to summarize there are two bugs: while doing what it is supposed to do These aren't glibc bugs, since this C program works correctly (its get #include <stdio.h> get calls match the set calls. (65534 is nobody on my machine) I can see the same behavior with all perls I have 5.005_03 - blead, perl -V Characteristics of this binary (from libperl): __________________________________________________________________ |
From @rgsStas Bekman (via RT) wrote:
Affecting PL_uid et alli from POSIX.xs should be quite easy. ...
They internally use PL_uid (most probably).
To summarize : easy to fix, but regression tests would be hard to write. |
From stas@stason.orgRafael Garcia-Suarez wrote:
Does it mean that you have a fix already? Cool!
Yes, the easiest is to run as root. They could be optional tests, though. I've also later discovered that: is not enough, as it doesn't quite change the group completely. Something The really right way to drop perms completely is to: notice that you pass the same group id for "other groups". also a few months ago I reported on behalf of one of the modperl users is that Therefore I ended up doing the actual attempts to read, write and execute to # this sub is executed from an external process only, since it # first must change gid and egid ("$gid $gid" for an empty # only now can change uid and euid my $file = catfile # unfortunately we can't run the what seems to be an obvious test: # -w # -x # -r # all tests passed If you are wondering what this function is for, it tests whether Apache will Thanks again to Jörg Walter for working this one out. p.s. I'm not 100% sure the example in perlsec is correct, as it changes uids __________________________________________________________________ |
From @rgsStas Bekman wrote:
(I may have mentioned this earlier) Does the filetest pragma help? |
From @rgsStas Bekman wrote:
I applied the following patch to bleadperl : (I tried to be the least intrusive possible -- more eyeballs welcome. Change 21958 by rgs@rgs-home on 2003/12/25 21:22:25 Fix bug [perl #24641] : when POSIX::set[ug]id() are called, Affected files ... ... //depot/perl/ext/POSIX/POSIX.xs#121 edit Differences ... ==== //depot/perl/ext/POSIX/POSIX.xs#121 (text) ==== @@ -1827,10 +1827,20 @@ SysRet SysRetLong |
@rgs - Status changed from 'new' to 'resolved' |
From stas@stason.orgRafael Garcia-Suarez wrote:
The original poster has never followed up on the proposed solution: Let me ping the modperl list, may be someone who has an access to acl based __________________________________________________________________ |
Migrated from rt.perl.org#24641 (status was 'resolved')
Searchable as RT24641$
The text was updated successfully, but these errors were encountered: