Home / server / Questions / 86868
Accepted
Michael H.
Asked: 2009-11-21 20:02:55 +0800 CST

su to user that doesn't exist any longer?

  • 772

I have an interesting situation, where a user's account has been temporarily removed (paperwork not renewed in time). However, thanks to the magic of "screen", his processes are still running.

I would love to be able to reconnect to those old screen sessions and save some data out. Is that possible? I have sudo powers, but am not sure how to apply them in this case.

Normally I would do:

  1. chmod 777 `tty`
  2. sudo su <user>
  3. screen -x

but the user no longer exists in this case. Naively plugging in the old user ID didn't work (not that I really expected it to).

This is RedHat Enteprise Linux 5: (2.6.18-53.1.14.el5)

linux

3 Answers

  1. Best Answer

    You can't just temporarily create the user account again using the same UID ?

    • 4

  2. OK, this is why users should be disabled, rather than removed. There are built-in options to passwd for that sort of thing (and settings exist in every centralized-user-management software that I know of for it).

    But you're not here to get yelled at.

    Do the user's files still exist, or were those removed with the account? Screen uses the lock files to reconnect, and if they're gone, I'm honestly not sure how to reclaim the sessions.

    Try Keiran's suggestion of recreating the UID if possible. Sometimes it isn't feasible, especially in a centralized authentication where the IDs are hashed from the other user information, but if you can, that would be swell.

    Assuming you can't, you need to find a way to take over the terminal. I'm going to guess that TTYSnoop isn't configured on your system already. In that case, it's going to get hairy.

    Assuming that your screen sessions issue you a pts/# terminal like mine do, there may (MAY) be a chance. pt stands for pseudoterminal, and it's sort of client/server based. There are the pt slaves, which is the terminal that you type with, and there is the ptmaster, that receives the input. There are many slaves (/dev/pts/*) to one pt master (/dev/ptmx). From the man page to ptmx: 

       Before  opening  the  pseudo-terminal slave, you must pass the master’s
   file descriptor to grantpt(3) and unlockpt(3).

   Once both the pseudo-terminal master and slave are open, the slave pro‐
   vides  processes  with an interface that is identical to that of a real
   terminal.

    It may (may!) be possible to assume the identity of the terminals that you want to assume (oh hell, might as well just say hijack at this point) using a custom written program that conveniently overlooks certain safety measures, like the pre-existence of the file descriptors you want.

    It's probably much less work at this point just to concede defeat and lose the data.

    • 2

  3. Have you tried, as root, to connect by specifying the running screen's socket name to screen? (I haven't tried this personally. )

    • 0