suidperl up to 5.06 -- local root compromise

[p5pRT]

Migrated from rt.perl.org#3645 (status was 'resolved')

Searchable as RT3645$

[p5pRT]

From lcamtuf@dione.ids.pl

I'm sorry for this little bit too late raport\, but I guess it's better than nothing :/ Yes\, you could blame me.

Here's how it works​:

-- snip! --

a) If you'll try to fool perl\, forcing it to execute one file instead   of another (quite complicated condition\, refer to source code)\, it   generates such mail to administrator​:

  From​: Bastard Operator \root@​nimue\.tpi\.pl   To​: root@​nimue.tpi.pl

  User 500 tried to run dev 769 ino 343180 in place of dev 769 ino 343183!   (Filename of set-id script was /some/thing\, uid 500 gid 500.)

  Sincerely\,   perl

  It is sent using /bin/mail root call with environment preserved.

  This condition is quite easy to reach - my code is extermely ugly and   slow (it's written in bash)\, so it requires reasonably fast machine   (like pII/pIII x86 box). It can be optimized\, of course.

b) In this mail\, you'll find script name\, taken from argv[1].

c) /bin/mail has undocumented feature; if interactive=something\, it will   interpret ~! sequence even if not running on the terminal; it is not   safe to use /bin/mail at privledged level.

Three things\, combined\, allows you to execute command using ~! passed in script name. This command creates suid shell.

-- snip! --

You can find more comments in attached source.

_______________________________________________________ Michal Zalewski [lcamtuf@​tpi.pl] [tp.internet/security] [http​://lcamtuf.na.export.pl] \<=--=> bash$ :(){ :|​:&};​: =-----=> God is real\, unless declared integer. \<=-----=

[p5pRT]

From lcamtuf@dione.ids.pl

xperl.sh

[p5pRT]

From [Unknown Contact. See original ticket]

Michal Zalewski (lists.p5p)​:

interpret ~! sequence even if not running on the terminal; it is not safe to use /bin/mail at privledged level.

Three things\, combined\, allows you to execute command using ~! passed in script name. This command creates suid shell.

Oh\, expletive. Mailing root is cute\, but security comes first. I vote we just kill the thing.

Thanks for the heads-up\, Michal.

Inline Patch

```diff --- perl.c~ Sun Aug 6 22:08:32 2000 +++ perl.c Sun Aug 6 22:10:13 2000 @@ -2851,6 +2851,7 @@ if (tmpstatbuf.st_dev != PL_statbuf.st_dev || tmpstatbuf.st_ino != PL_statbuf.st_ino) { (void)PerlIO_close(PL_rsfp); +#ifdef DISGUSTINGLY_INSECURE if (PL_rsfp = PerlProc_popen("/bin/mail root","w")) { /* heh, heh */ PerlIO_printf(PL_rsfp, "User %"Uid_t_f" tried to run dev %ld ino %ld in place of dev %ld ino %ld!\n\ @@ -2861,6 +2862,7 @@ PL_statbuf.st_uid, PL_statbuf.st_gid); (void)PerlProc_pclose(PL_rsfp); } +#endif Perl_croak(aTHX_ "Permission denied\n"); } if ( ```

[p5pRT]

From @jhi

On Sun\, Aug 06\, 2000 at 01​:13​:45PM +0000\, Simon Cozens wrote​:

Michal Zalewski (lists.p5p)​:

interpret ~! sequence even if not running on the terminal; it is not safe to use /bin/mail at privledged level.

Three things\, combined\, allows you to execute command using ~! passed in script name. This command creates suid shell.

Oh\, expletive. Mailing root is cute\, but security comes first. I vote we just kill the thing.

Oh\, expletive. I vote we just kill the suidperl.

[p5pRT]

From [Unknown Contact. See original ticket]

Jarkko Hietaniemi (lists.p5p)​:

I vote we just kill the suidperl.

Well\, yes\, there is that. I don't run suidperl anywhere on my machines\, and I can't see anywhere where suidperl is being installed by default. Where does this monstrosity come from?

[p5pRT]

From [Unknown Contact. See original ticket]

Simon Cozens [simon@​brecon.co.uk] quoth​: *>Jarkko Hietaniemi (lists.p5p)​: *>> I vote we just kill the suidperl. *> *>Well\, yes\, there is that. I don't run suidperl anywhere on my machines\, *>and I can't see anywhere where suidperl is being installed by default. *>Where does this monstrosity come from?

http​://www.cpan.org/clpa/1996-06/358 was\, iirc\, the first CERT advisory for it in June 1996. It stemmed from the need for a secure way to execute scripts as another user without using the setuid bit and with other features to make it more bullet-proof. I've never actually compiled a setuid Perl so I can't acknowledge nor deny it's bugs but I imagine it should go the way of /eg as it has outlived its time. I might also note that the Camel3 makes NO mention of setuid Perl and has a nicely done section on security.

I'm curious about the actual origin of setuid Perl [ was it Tim Bunce?? my memory is going it would seem ] and which version of Perl4 it was introduced with.

e.

[p5pRT]

From [Unknown Contact. See original ticket]

In message \slrn8otk56\.d11\.simon@&#8203;othersideofthe\.earth\.li   simon@​brecon.co.uk (Simon Cozens) wrote​:

Jarkko Hietaniemi (lists.p5p)​:

I vote we just kill the suidperl.

Well\, yes\, there is that. I don't run suidperl anywhere on my machines\, and I can't see anywhere where suidperl is being installed by default. Where does this monstrosity come from?

It is installed by default on linux systems as for some reason linux doesn't have secure scripts.

Tom

[p5pRT]

From [Unknown Contact. See original ticket]

Elaine -HFB- Ashton \elaine@​chaos\.wustl\.edu writes​:		I'm curious about the actual origin of setuid Perl [ was it Tim Bunce?? my		memory is going it would seem ] and which version of Perl4 it was		introduced with.
e.

I'm sure it was in perl 3 - it was a concious decision to not include it with our distribution from the very beginning.

[p5pRT]

From [Unknown Contact. See original ticket]

On Mon\, Aug 07\, 2000 at 11​:26​:16AM -0500\, HappyFunBall wrote​:

Simon Cozens [simon@​brecon.co.uk] quoth​: *>Jarkko Hietaniemi (lists.p5p)​: *>> I vote we just kill the suidperl. *> *>Well\, yes\, there is that. I don't run suidperl anywhere on my machines\, *>and I can't see anywhere where suidperl is being installed by default. *>Where does this monstrosity come from?

http​://www.cpan.org/clpa/1996-06/358 was\, iirc\, the first CERT advisory for it in June 1996. It stemmed from the need for a secure way to execute scripts as another user without using the setuid bit and with other features to make it more bullet-proof. I've never actually compiled a setuid Perl so I can't acknowledge nor deny it's bugs but I imagine it should go the way of /eg as it has outlived its time.

  It hasn't. I use it quite a bit. I agree that it shouldn't be installed by default\, though.

  Peace\, * Kurt Starsinic (kstar@​orientation.com) ---------- Senior Network Engineer * | `If we knew what it was we were doing\, it wouldn't be called | | research\, would it?' -- Albert Einstein |

[p5pRT]

From @jhi

On Tue\, Aug 08\, 2000 at 05​:41​:37PM -0400\, Kurt D. Starsinic wrote​:

On Mon\, Aug 07\, 2000 at 11​:26​:16AM -0500\, HappyFunBall wrote​:

Simon Cozens [simon@​brecon.co.uk] quoth​: *>Jarkko Hietaniemi (lists.p5p)​: *>> I vote we just kill the suidperl. *> *>Well\, yes\, there is that. I don't run suidperl anywhere on my machines\, *>and I can't see anywhere where suidperl is being installed by default. *>Where does this monstrosity come from?

http​://www.cpan.org/clpa/1996-06/358 was\, iirc\, the first CERT advisory for it in June 1996. It stemmed from the need for a secure way to execute scripts as another user without using the setuid bit and with other features to make it more bullet-proof. I've never actually compiled a setuid Perl so I can't acknowledge nor deny it's bugs but I imagine it should go the way of /eg as it has outlived its time.

It hasn't\.  I use it quite a bit\.  I agree that it shouldn't be

installed by default\, though.

Ha-haa! A real living suidperl user. What do you it *for*? Why?

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, Aug 08\, 2000 at 05​:23​:06PM -0500\, Jarkko Hietaniemi wrote​:

On Tue\, Aug 08\, 2000 at 05​:41​:37PM -0400\, Kurt D. Starsinic wrote​:

On Mon\, Aug 07\, 2000 at 11​:26​:16AM -0500\, HappyFunBall wrote​:

Simon Cozens [simon@​brecon.co.uk] quoth​: *>Jarkko Hietaniemi (lists.p5p)​: *>> I vote we just kill the suidperl. *> *>Well\, yes\, there is that. I don't run suidperl anywhere on my machines\, *>and I can't see anywhere where suidperl is being installed by default. *>Where does this monstrosity come from?

http​://www.cpan.org/clpa/1996-06/358 was\, iirc\, the first CERT advisory for it in June 1996. It stemmed from the need for a secure way to execute scripts as another user without using the setuid bit and with other features to make it more bullet-proof. I've never actually compiled a setuid Perl so I can't acknowledge nor deny it's bugs but I imagine it should go the way of /eg as it has outlived its time.

It hasn't\.  I use it quite a bit\.  I agree that it shouldn't be

installed by default\, though.

Ha-haa! A real living suidperl user. What do you it *for*? Why?

  I have one directory on all my servers that's rsynced (over an ssh tunnel). All the programs in there are setuid root\, and they're all written and reviewed by me. They're written in Perl\, so they're cross platform. Some are intended to be run by anyone\, some by everyone in a particular group\, and some just by the admins. I find them particularly useful for running root jobs remotely via ssh\, because I don't allow root login to any of my machines. My live would be dismal without setuid perl.

  Further details on request.

  Peace\, * Kurt Starsinic (kstar@​orientation.com) ---------- Senior Network Engineer * | `Disease and deprivation stalk our land like -- | | two giant stalking things.' - Blackadder |

[p5pRT]

From [Unknown Contact. See original ticket]

Kurt D Starsinic \kstar@&#8203;chapin\.edu writes​:

I have one directory on all my servers that's rsynced (over an ssh tunnel). All the programs in there are setuid root\, and they're all written and reviewed by me. They're written in Perl\, so they're cross platform. Some are intended to be run by anyone\, some by everyone in a particular group\, and some just by the admins. I find them particularly useful for running root jobs remotely via ssh\, because I don't allow root login to any of my machines. My live would be dismal without setuid perl.

This is precisely what sudo is for. Why duplicate sudo and have to do security checks on a whole directory full of scripts instead of just using it?

[p5pRT]

From @jhi

Ha-haa! A real living suidperl user. What do you it *for*? Why?

I have one directory on all my servers that's rsynced \(over an

ssh tunnel). All the programs in there are setuid root\, and they're all written and reviewed by me. They're written in Perl\, so they're cross platform. Some are intended to be run by anyone\, some by everyone in a particular group\, and some just by the admins. I find them particularly useful for running root jobs remotely via ssh\, because I don't allow root login to any of my machines. My live would be dismal without setuid perl.

You are willing to live with a root exploit once in a while? You are willing to let many other Perl users to live with a root exploit once in a while?

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, Aug 08\, 2000 at 05​:44​:51PM -0500\, Jarkko Hietaniemi wrote​:

You are willing to live with a root exploit once in a while? You are willing to let many other Perl users to live with a root exploit once in a while?

My 2 cents...

At a minimum\, suidperl should be made a NON-default option when building Perl. Just like I'm asked about malloc\, threads\, and whatnot. And then we just hope that OS vendors will leave it out.

Better yet\, it should be dropped completely. Convince people to look at tools like sudo for their "run this SUID" needs.

I get annoyed having to hop on 10 different machines and `sudo rm -f /usr/bin/suidperl' and then wonder why it was there in the first place.

Is there a suidpython? Or suidtcl? Or suidbash?

But I've also become quite a bit more security conscious in recent years. So I tend to lean toward removing suidperl.

Jeremy

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, Aug 08\, 2000 at 03​:43​:50PM -0700\, Russ Allbery wrote​:

Kurt D Starsinic \kstar@&#8203;chapin\.edu writes​:

I have one directory on all my servers that's rsynced (over an ssh tunnel). All the programs in there are setuid root\, and they're all written and reviewed by me. They're written in Perl\, so they're cross platform. Some are intended to be run by anyone\, some by everyone in a particular group\, and some just by the admins. I find them particularly useful for running root jobs remotely via ssh\, because I don't allow root login to any of my machines. My live would be dismal without setuid perl.

This is precisely what sudo is for. Why duplicate sudo and have to do security checks on a whole directory full of scripts instead of just using it?

  Every sudo I know of prompts for a password. That doesn't fulfill my needs.

  Peace\, * Kurt Starsinic (kstar@​orientation.com) ---------- Senior Network Engineer * | `The future masters of technology will have to be lighthearted and | | intelligent. The machine easily masters the grim and the dumb.' | | -- Marshall McLuhan |

[p5pRT]

From [Unknown Contact. See original ticket]

On Tue\, Aug 08\, 2000 at 05​:44​:51PM -0500\, Jarkko Hietaniemi wrote​:

Ha-haa! A real living suidperl user. What do you it *for*? Why?

I have one directory on all my servers that's rsynced \(over an

ssh tunnel). All the programs in there are setuid root\, and they're all written and reviewed by me. They're written in Perl\, so they're cross platform. Some are intended to be run by anyone\, some by everyone in a particular group\, and some just by the admins. I find them particularly useful for running root jobs remotely via ssh\, because I don't allow root login to any of my machines. My live would be dismal without setuid perl.

You are willing to live with a root exploit once in a while?

  I believe that I do a good job of protecting against (and\, potentially\, reacting to) them on my servers. Frankly\, I've had a much worse time with email infrastructure than I ever have with suidperl.

You are willing to let many other Perl users to live with a root exploit once in a while?

  I don't think that suidperl should be built by default. I am willing to let sophisticated users with root access play with fire; after all\, they will anyway.

  How would you feel about making suidperl `experimental'?

  Peace\, * Kurt Starsinic (kstar@​orientation.com) ---------- Senior Network Engineer * | `Focusing our research on cryptographic protocols for secure electronic | | commerce is akin to investing all our money to build heavily armored | | cars. However\, those armored cars will spend their lifetimes | | transferring checks written in crayon by people on park benches to | | merchants doing business in cardboard boxes under highway overpasses. | | Meanwhile\, there are no traffic regulations\, anyone on a skateboard | | can change the traffic lights with a screwdriver\, and there are no | | police.' -- Eugene Spafford |

[p5pRT]

From @jhi

You are willing to live with a root exploit once in a while?

I believe that I do a good job of protecting against \(and\, potentially\,

reacting to) them on my servers. Frankly\, I've had a much worse time with

I'm not suspecting your skills. If you have complete control over your environment\, good.

email infrastructure than I ever have with suidperl.

You are willing to let many other Perl users to live with a root exploit once in a while?

I don't think that suidperl should be built by default\.  I am willing

I don't think it is. Someone must explicitly ask for it.

to let sophisticated users with root access play with fire; after all\, they will anyway.

How would you feel about making suidperl \`experimental'?

How would you feel about making suidperl `nonexistent'? No\, wait\, I already asked that...

Somebody with good 'software hardening' experience should go through suidperl. I've seen people going to software not only using the source code\, but by using system call tracing and looking for patterns that spell 'race condition' or something other yucky.

[p5pRT]

From [Unknown Contact. See original ticket]

Jarkko Hietaniemi (lists.p5p)​:

Somebody with good 'software hardening' experience should go through suidperl. I've seen people going to software not only using the source code\, but by using system call tracing and looking for patterns that spell 'race condition' or something other yucky.

Well\, maybe we can get the man Theo DeRaadt (and the OpenBSD team) to have a look at it. If anyone know anything about security auditing\, those guys do. The vunerable parts are identified mainly by IAMSUID\, but there may be knock-on effects that merely looking at #ifdef IAMSUID sections will not warn you about. (I'm thinking about things like spawning external processes. Does suidperl turn on taint mode by default? It really\, really\, really\, really\, really\, really\, really ought to.)

If anyone wants to audit suidperl\, I'm happy to provide a sherpa service to the Perl source.

[p5pRT]

From @jhi

On Wed\, Aug 09\, 2000 at 04​:34​:03PM +0000\, Simon Cozens wrote​:

Jarkko Hietaniemi (lists.p5p)​:

Somebody with good 'software hardening' experience should go through suidperl. I've seen people going to software not only using the source code\, but by using system call tracing and looking for patterns that spell 'race condition' or something other yucky.

Well\, maybe we can get the man Theo DeRaadt (and the OpenBSD team) to have a look at it. If anyone know anything about security auditing\, those guys do. The vunerable parts are identified mainly by IAMSUID\, but there may be knock-on effects that merely looking at #ifdef IAMSUID sections will not warn you about. (I'm thinking about things like spawning

I forwarded the idea to Todd Miller.

external processes. Does suidperl turn on taint mode by default? It really\, really\, really\, really\, really\, really\, really ought to.)

If anyone wants to audit suidperl\, I'm happy to provide a sherpa service to the Perl source.

-- "So i get the chance to reread my postings to asr at times\, with a corresponding conservation of the almighty leviam00se\, Kai Henningsen." -- Megahal (trained on asr)\, 1998-11-06

[p5pRT]

From [Unknown Contact. See original ticket]

"Kurt D. Starsinic" wrote​:

On Tue\, Aug 08\, 2000 at 03​:43​:50PM -0700\, Russ Allbery wrote​:

This is precisely what sudo is for. Why duplicate sudo and have to do security checks on a whole directory full of scripts instead of just using it?

Every sudo I know of prompts for a password\.  That doesn't fulfill

my needs.

I believe you can configure sudo with the "--disable-authentication" option\, which turns off password prompting\, forcing you to assume that the user obtained access to the session legitimately.

http​://www.courtesan.com/sudo/install.html

Regards.

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, 9 Aug 2000 11​:26​:50 -0500\, Jarkko Hietaniemi wrote (in part)​:

jhi> Somebody with good 'software hardening' experience should go jhi> through suidperl. I've seen people going to software not jhi> only using the source code\, but by using system call tracing jhi> and looking for patterns that spell 'race condition' or jhi> something other yucky.

As long as that gives some hope of the survival of suidperl\, I'm quite happy to undertake that. After all\, it is directly related to my "day job". I'd looked at it some before\, but didn't give it enough thought at the time to realize that someone might add "features" to /bin/mail. I'll do system call tracing on my uses of it at home and see what I find\, along with doing a real code inspection of the suidperl-specific portions of the code.

[p5pRT]

From @jhi

On Wed\, Aug 09\, 2000 at 12​:37​:07PM -0400\, spider-perl@​Orb.Nashua.NH.US wrote​:

On Wed\, 9 Aug 2000 11​:26​:50 -0500\, Jarkko Hietaniemi wrote (in part)​:

jhi> Somebody with good 'software hardening' experience should go jhi> through suidperl. I've seen people going to software not jhi> only using the source code\, but by using system call tracing jhi> and looking for patterns that spell 'race condition' or jhi> something other yucky.

As long as that gives some hope of the survival of suidperl\, I'm quite happy to undertake that. After all\, it is directly related to my "day job". I'd looked at it some before\, but didn't give it enough thought at the time to realize that someone might add "features" to /bin/mail. I'll do system call tracing on my uses of it at home and see what I find\, along with doing a real code inspection of the suidperl-specific portions of the code.

Excellent! Thank you.

[p5pRT]

From [Unknown Contact. See original ticket]

spider-perl@​Orb.Nashua.NH.US wrote

As long as that gives some hope of the survival of suidperl\, I'm quite happy to undertake that. After all\, it is directly related to my "day job". I'd looked at it some before\, but didn't give it enough thought at the time to realize that someone might add "features" to /bin/mail. I'll do system call tracing on my uses of it at home and see what I find\, along with doing a real code inspection of the suidperl-specific portions of the code.

I trust that\, irrespective of the results of the inspection\, the use of /bin/mail is scrapped.

Or phrased differently\, *any* use of an external program discovered during the code inspection should be considered dubious.

Mike Guy

[p5pRT]

From [Unknown Contact. See original ticket]

Mike Guy wrote​:

spider-perl@​Orb.Nashua.NH.US wrote

As long as that gives some hope of the survival of suidperl\, I'm quite happy to undertake that. After all\, it is directly related to my "day job". I'd looked at it some before\, but didn't give it enough thought at the time to realize that someone might add "features" to /bin/mail. I'll do system call tracing on my uses of it at home and see what I find\, along with doing a real code inspection of the suidperl-specific portions of the code.

I trust that\, irrespective of the results of the inspection\, the use of /bin/mail is scrapped.

Or phrased differently\, *any* use of an external program discovered during the code inspection should be considered dubious.

  Is it not reasonable to revert to real uid/gid and then run   /bin/mail or whatever other external program?  

[p5pRT]

From [Unknown Contact. See original ticket]

Kurt D. Starsinic [kstar@​chapin.edu] quoth​: *> *> I don't think that suidperl should be built by default. I am willing *>to let sophisticated users with root access play with fire; after all\, they *>will anyway.

A patch to be applied to the main dist could be made that would make it blatant that it isn't supported and possibly dangerous?

Have you considered networkshell for distributed jobs? setuid stuff is less sophisticated to me than using root only when absolutely necessary and even then sparingly.

*> How would you feel about making suidperl `experimental'?

Well...threads are 'experimental' but that doesn't seem to be obvious enough does it?

e.

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Aug 09\, 2000 at 02​:07​:03PM -0400\, Norton Allen wrote​:

Mike Guy wrote​:

spider-perl@​Orb.Nashua.NH.US wrote

As long as that gives some hope of the survival of suidperl\, I'm quite happy to undertake that. After all\, it is directly related to my "day job". I'd looked at it some before\, but didn't give it enough thought at the time to realize that someone might add "features" to /bin/mail. I'll do system call tracing on my uses of it at home and see what I find\, along with doing a real code inspection of the suidperl-specific portions of the code.

I trust that\, irrespective of the results of the inspection\, the use of /bin/mail is scrapped.

Or phrased differently\, *any* use of an external program discovered during the code inspection should be considered dubious.

Is it not reasonable to revert to real uid/gid and then run /bin/mail or whatever other external program?

  I think that it was a silly feature. If one wants to argue to support it\, then it should probably only connect directly to an SMTP port somewhere\, else you're opening a can of Trojan worms (a Trojan can of worms?).

  - Kurt

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed\, Aug 09\, 2000 at 01​:36​:13PM -0500\, HappyFunBall wrote​:

Kurt D. Starsinic [kstar@​chapin.edu] quoth​: *> *> I don't think that suidperl should be built by default. I am willing *>to let sophisticated users with root access play with fire; after all\, they *>will anyway.

A patch to be applied to the main dist could be made that would make it blatant that it isn't supported and possibly dangerous?

  I like the fact that the Linux kernel has a `I am interested in experimental features' flag\, which must be set for me to even _see_ the experimental features during the configuration process. I'd like to see something like that for Perl\, and put suidperl in that class of features.

Have you considered networkshell for distributed jobs? setuid stuff is less sophisticated to me than using root only when absolutely necessary and even then sparingly.

  Paul Visscher has pointed out that sudo has a NOPASSWD option that can be applied to individual entries. Pending an investigation as to whether it's supported on all versions of Linux\, Solaris\, and FreeBSD that I deal with\, I retract my strongly-worded statement re​: my life depending on suidperl.

*> How would you feel about making suidperl `experimental'?

Well...threads are 'experimental' but that doesn't seem to be obvious enough does it?

  Please see my first comment above. IMHO\, people shouldn't even _see_ threads as an option if they haven't asked for trouble.

  Peace\, * Kurt Starsinic (kstar@​orientation.com) ---------- Senior Network Engineer * | `The future masters of technology will have to be lighthearted and | | intelligent. The machine easily masters the grim and the dumb.' | | -- Marshall McLuhan |

[p5pRT]

From [Unknown Contact. See original ticket]

Jarkko Hietaniemi \jhi@&#8203;iki\.fi writes​:

Ha-haa! A real living suidperl user. What do you it *for*? Why?

I have one directory on all my servers that's rsynced \(over an

ssh tunnel). All the programs in there are setuid root\, and they're all written and reviewed by me. They're written in Perl\, so they're cross platform. Some are intended to be run by anyone\, some by everyone in a particular group\, and some just by the admins. I find them particularly useful for running root jobs remotely via ssh\, because I don't allow root login to any of my machines. My live would be dismal without setuid perl.

You are willing to live with a root exploit once in a while? You are willing to let many other Perl users to live with a root exploit once in a while?

Kurt is quite capable of creating a suidperl for himself if he really wants one.

[p5pRT]

From [Unknown Contact. See original ticket]

Kurt D. Starsinic [kstar@​chapin.edu] quoth​: *> *> I like the fact that the Linux kernel has a `I am interested in *>experimental features' flag\, which must be set for me to even _see_ *>the experimental features during the configuration process. I'd like *>to see something like that for Perl\, and put suidperl in that class *>of features.

Sure\, but experimental stuff is just the kind of thing that gets people into trouble which is why I suggested a completely separate patch so that it would be a conscious and deliberate activity.

*> Paul Visscher has pointed out that sudo has a NOPASSWD option that *>can be applied to individual entries. Pending an investigation as to *>whether it's supported on all versions of Linux\, Solaris\, and FreeBSD *>that I deal with\, I retract my strongly-worded statement re​: my life *>depending on suidperl.

You could also use ssh with RSA authentication. The sudo feature works on Solaris and *BSD ...no idea about linux though.

*> Please see my first comment above. IMHO\, people shouldn't even _see_ *>threads as an option if they haven't asked for trouble.

How many of those have 'forgotten' the experimental status and sent in complaints about the instability?

The bottom line is that if it is a horrible noose then it should be removed and labled as such. I mean a programming language getting a CERT advisory? How odd is that....geesh.

Get with the 21st century man\, wrappers are so....90s :)

e.

[p5pRT]

From [Unknown Contact. See original ticket]

Elaine -HFB- Ashton [elaine@​chaos.wustl.edu] said​:

The sudo feature works on Solaris and *BSD ...no idea about linux though.

The NOPASSWD feature works in Linux as well.

Paul

[p5pRT]

From @rspier

"KDS" == Kurt D Starsinic \kstar@&#8203;chapin\.edu writes​: KDS> Every sudo I know of prompts for a password. That doesn't KDS> fulfill my needs.

It is possible to configure around this.

For example\, this entry in /etc/sudoers allows george to become all users using my password\, but run /usr/bin/quota with no password.

george ALL=(ALL) ALL\, NOPASSWD​: /usr/bin/quota

-R

[p5pRT]

From The RT System itself

The popen("/bin/mail") code removed.