Bug 567210

Summary: RFE: allow access to terminal after su
Product: [Fedora] Fedora Reporter: Karel Volný <kvolny>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: kdudka, mlichvar, ovasik, tmraz, twaugh
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-15 14:27:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Karel Volný 2010-02-22 04:50:41 EST
Description of problem:
I'd like to run a process as another user, leaving it in screen session that can be reconnected from another session. While it works without any troubles on Gentoo, it seems impossible on Fedora ...

Version-Release number of selected component (if applicable):
screen-4.0.3-15.fc12

How reproducible:
always

Steps to Reproduce:
1. add two users (user1, user2)
2. log into X as user1
3. run terminal program
4. su - user2
5. screen
  
Actual results:
Cannot open your terminal '/dev/pts/6' - please check.

Expected results:
(new screen session is opened)

Additional info:
disabling selinux (setenforce 0) makes no difference
Comment 1 Miroslav Lichvar 2010-07-28 11:25:32 EDT
Screen requires access to the terminal, so you'll need to change its permissions or create a new pty by logging via ssh, etc.

Gentoo package has probably enabled setuid root on the screen binary, which we are not using for security reasons.
Comment 2 Karel Volný 2010-08-09 14:23:45 EDT
okay, may I turn this into RFE?

(In reply to comment #1)
> Screen requires access to the terminal, so you'll need to change its
> permissions or create a new pty by logging via ssh, etc.

couldn't there be a wrapper which makes the necessary setup for me?
(don't know what ssh does, couldn't we just do something similar?)

the problem is ... when you are not root to set arbitrary permissions on anything, and you have disabled ssh for some account
(any other workarounds?)

> Gentoo package has probably enabled setuid root on the screen binary, which we
> are not using for security reasons.    

no, it has just SGID:

# ls -l /usr/bin/screen 
-rwxr-s--x 1 root utmp 354760 12. kvě 18.45 /usr/bin/screen

but it is not the same group as PTS has:

# ls -l /dev/pts/1
crw--w---- 1 root tty 136, 1  9. srp 20.17 /dev/pts/1

so there has to be some "magic" in it ... couldn't you do some similar trick?
Comment 3 Karel Volný 2010-08-10 03:47:19 EDT
(In reply to comment #2)
> couldn't there be a wrapper which makes the necessary setup for me?

hm, thinking about that further ... couldn't there be something in 'su' itself to allow the access to the pty of the user that runs 'su'? - is 'screen' the only application which needs this?
Comment 4 Karel Volný 2010-08-10 08:38:52 EDT
(In reply to comment #2)
> > Gentoo package has probably enabled setuid root on the screen binary, which we
> > are not using for security reasons.    
> 
> no, it has just SGID:
> 
> # ls -l /usr/bin/screen 
> -rwxr-s--x 1 root utmp 354760 12. kvě 18.45 /usr/bin/screen
> 
> but it is not the same group as PTS has:
> 
> # ls -l /dev/pts/1
> crw--w---- 1 root tty 136, 1  9. srp 20.17 /dev/pts/1
> 
> so there has to be some "magic" in it ... couldn't you do some similar trick?    

seems I was mistaken ... it stopped working for me on Gentoo while I have not noticed, and it seems that it worked for me before because it was using SUID in the past
Comment 5 Karel Volný 2010-08-10 08:44:34 EDT
(In reply to comment #3)
> hm, thinking about that further ... couldn't there be something in 'su' itself
> to allow the access to the pty of the user that runs 'su'? - is 'screen' the
> only application which needs this?    

this looks like the way to go, so changing the subject once again and reassigning to coreutils
Comment 6 Kamil Dudka 2010-08-17 09:05:21 EDT
AFAIK su code itself does not anyhow change permissions nor ownership of the terminal.  We only pass the terminal name to PAM:

    retval = pam_set_item(pamh, PAM_TTY, tty_name);

I am not sure if PAM is capable to do what you want.  I am adding its maintainer to CC.
Comment 7 Tomas Mraz 2010-08-17 09:19:49 EDT
Nope, there is no such PAM module.
Comment 8 Kamil Dudka 2010-08-17 09:40:23 EDT
Note you can change permissions of the terminal manually before invoking su.
Comment 9 Bug Zapper 2011-06-02 12:26:54 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Karel Volný 2011-06-15 14:27:31 EDT
hm, seems this works in Fedora 15 ...
Comment 11 Tomas Mraz 2011-06-15 14:39:04 EDT
Yes, it seems that screen now just opens a new pty in this case.