Bug #50891 for IO-Tty: Cannot create a new IO::Pty

Tue Oct 27 18:41:08 2009 lordadmira [...] yahoo.com - Ticket created

Subject:

Cannot create a new IO::Pty

Hi. I'm trying to use IO::Tty in a setuid script but it's crashing. It works fine non setuid. I have a little C wrapper that posseses the setuid permission that calls the Perl script. When I run the wrapper as another user everything works until the new pty creation. IO::Tty::open_slave(nonfatal): open(/dev/pts/0): Permission denied at /export/home/user/lib/PA-RISC1.1-thread-multi/IO/Pty.pm line 24. pty_allocate(nonfatal): open(/dev/ptmx): Permission denied at /export/home/user/lib/PA-RISC1.1-thread-multi/IO/Pty.pm line 24. IO::Tty::pty_allocate(nonfatal): grantpt(): Invalid argument at /export/home/user/lib/PA-RISC1.1-thread-multi/IO/Pty.pm line 24. IO::Tty::pty_allocate(nonfatal): unlockpt(): Invalid argument at /export/home/user/lib/PA-RISC1.1-thread-multi/IO/Pty.pm line 24. IO::Tty::open_slave(nonfatal): open(/dev/pts/0): Permission denied at /export/home/user/lib/PA-RISC1.1-thread-multi/IO/Pty.pm line 24. pty_allocate(nonfatal): open(/dev/ptym/clone): Permission denied at /export/home/user/lib/PA-RISC1.1-thread-multi/IO/Pty.pm line 24. Cannot create a new IO::Pty from fd 4: Bad file number at /export/home/user/IDR/IDRconfigdiff.pl line 298 It has to be setuid so that the script users can't directly access certain information. It just changes to another user ID, not root. The only related thing I found online was http://wiki.cpaneldirect.net/wiki/index.php/Cannot_create_a_new_IO::Tty_from_fd_4:_Bad_file_descriptor. Trying the suggestion there of removing -DHAVE_UNLOCKPT from the make file made the module non compilable. # perl -v This is perl, v5.8.8 built for PA-RISC1.1-thread-multi (with 26 registered patches, see perl -V for more detail) Copyright 1987-2006, Larry Wall Binary build 817 [257965] provided by ActiveState http://www.ActiveState.com Built Mar 20 2006 19:44:08 # uname -a HP-UX mse07 B.11.11 U 9000/800 3267743758 unlimited-user license

Tue Feb 23 11:57:28 2010 RGiersig [...] cpan.org - Correspondence added

Show quoted text

> It has to be setuid so that the script users can't directly access > certain information. It just changes to another user ID, not root.

Looks like this other user ID is too restricted to open the device files in /dev. What happens if you run the script directly as that user without the suid part in between? -- RGiersig@cpan.org

Tue Feb 23 11:57:29 2010 The RT System itself - Status changed from 'new' to 'open'

Tue Feb 23 11:57:29 2010 RGiersig [...] cpan.org - Status changed from 'open' to 'stalled'

Tue Feb 23 12:08:09 2010 lordadmira [...] yahoo.com - Correspondence added

From:

lordadmira [...] yahoo.com

It works fine. Both accounts are ordinary user accounts. Once setuid is dropped, the pty can be made and the connection can proceed. However this means I can't do any work as setuid after the pty is made.

Tue Feb 23 12:08:17 2010 The RT System itself - Status changed from 'stalled' to 'open'

Sun Oct 03 01:13:02 2010 TODDR [...] cpan.org - Status changed from 'open' to 'stalled'

Sun Oct 03 01:17:39 2010 TODDR [...] cpan.org - Correspondence added

Test suites could never test setuid so this would be really hard to prove out. My best guess is that setuid restricts this kind of activity for some sort of security reason. Or the perl you have is being restrictive in some way. Have you run a strace (or equivalent) to see what's failing I also don't have access to your OS so we would need much more debugging to even come close to guessing the fix on this one.

Sun Oct 03 01:17:42 2010 The RT System itself - Status changed from 'stalled' to 'open'

Sun Oct 03 01:18:03 2010 TODDR [...] cpan.org - Status changed from 'open' to 'stalled'

Sun Oct 03 01:18:04 2010 TODDR [...] cpan.org - Severity Critical changed to Normal

Sun Dec 14 03:05:55 2014 TODDR [...] cpan.org - Status changed from 'stalled' to 'rejected'