Front page | perl.perl5.porters |
Postings from April 2012
On Tue, Apr 10, 2012 at 2:17 PM, David Ingamells <david.ingamells@mapscape.eu> wrote: > The action isn't SET but SWAP. An executable with the sticky bit set gets 2 > user IDs available to it: the real ID and the effective ID. The real ID is > the ID of the user who runs the executable and the effective ID is the > owner of the executable. You're forgetting about the saved id (which you confusingly did mention in your patch). This saved ID was introduced exactly for this kind of scenario: temporarily dropping privileges. On exec*, it's set to the new effective id, so that when you change the effective id to the real one, you can still change it back. Setting any id other than the effective one is rarely necessary, and even then you probably want to set the saved id. See Proc::UID on CPAN for a nice implementation of this. > This is a known and well documented Unix practice, e.g. for a number of > Unix/GNU Linux commands where the effective ID is root, although in my case > the effective ID is not a privileged user. A very easy to understand example > is the unix command "passwd" which needs to be able to store the user's > new password without allowing the user to get at the store directly. > > Here are some of the GNU/Linux executables that have the "s" bit set - from > Ubuntu 10.04 released in 2010, well into the 21st century - which AFIK is > part of the current millennium ;-) > $ ls -l /usr/bin | egrep "^...s" > -rwsr-sr-x 1 root root 10536 Jan 18 19:49 X > -rwsr-xr-x 1 root root 14720 Mar 12 2010 arping > -rwsr-sr-x 1 daemon daemon 52032 Jan 15 2011 at > -rwsr-xr-x 1 root root 41864 Feb 14 2011 chfn > -rwsr-xr-x 1 root root 37128 Feb 14 2011 chsh > -rwsr-xr-x 1 root root 11214 Oct 22 2010 fileshareset > -rwsr-xr-x 1 root root 59752 Feb 14 2011 gpasswd > -rwsr-xr-x 1 root root 10480 Oct 22 2010 kgrantpty > -rwsr-xr-x 1 root root 10536 Oct 22 2010 kpac_dhcp_helper > -rwsr-xr-- 1 root dialout 644872 Apr 16 2011 kppp > -rwsr-xr-x 1 root root 47968 Oct 11 21:14 ksu > -rwsr-xr-x 1 root lpadmin 14256 Sep 12 2011 lppasswd > -rwsr-xr-x 1 root root 32416 Feb 14 2011 newgrp > -rwsr-xr-x 1 root root 42856 Feb 14 2011 passwd > -rwsr-xr-x 1 root root 19112 Apr 19 2011 pkexec > -rwsr-xr-x 1 root root 73216 Apr 22 2011 sperl5.10.1 > -rwsr-xr-x 1 root root 10528 Oct 22 2010 start_kdeinit > -rwsr-xr-x 2 root root 148024 Jan 19 2011 sudo > -rwsr-xr-x 2 root root 148024 Jan 19 2011 sudoedit > -rwsr-xr-x 1 root root 18928 Mar 12 2010 traceroute6.iputils > > This feature is also documented in the core Perl documentation. It would be pleasant if you would assume I have a clue of what I'm talking about while I'm helping you with a bug. If you don't understand my question, can you ask for a clarification instead of assuming I'm incompetent? > My code needs to SWAP the real and effective IDs, create/modify a file with > the effective ID as owner (so that the user whose ID is the effective ID can > manage the file) and SWAP back to the real user ID to create some other > files for the user. That's all I needed to know. You just want to reversibly set the effective user id. You don't really need to swap it with the real user id to achieve that. > It seems then that someone else has discovered the bug and it has been fixed > since 5.12. I'm not seeing any obvious changes that would explain that in the history. Until last February, the code directly involved hadn't been touched majorly since 2003. This looks to me like it's either an action at a distance, debian/ubuntu patching perl in weird ways, or both. > I, for one, will be very upset if that idiom is removed. It will turn a > trivial implementation in my code into a major headache. Quite to the contrary. It would make everyone's code easier: yours and ours. LeonThread Previous