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
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.
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?
(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?
(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
(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
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.
Nope, there is no such PAM module.
Note you can change permissions of the terminal manually before invoking su.
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
hm, seems this works in Fedora 15 ...
Yes, it seems that screen now just opens a new pty in this case.