1. Forum
  2. Usenet
  3. COMP.UNIX.PROGRAMMER

  • Changing the "controlling terminal" of a process?

    From Kenny McCormack@21:1/5 to All on Wed Aug 16 16:32:46 2023
    (In Linux)
    I need to be able to change the "controlling terminal" of an arbitrary
    process. I have read the doc for the ioctl TIOCSCTTY, but as far as I can tell, that only works for the calling process. Also, it seems to have some (IMHO) weird limitations. So, Q1: Is there any other system call for this?

    Note: I note that a lot of the "classic Unix" calls in this general area (process/session/controlling tty stuff) are specifically only able to
    affect the calling process, but that Linux has expanded on this - often allowing arbitrary processes to be affected.

    Also, Q2: Is it true that any given tty can only be the controlling
    terminal of (at most) one session? The doc for TIOCSCTTY seems to imply
    this.

    --
    "Everything Roy (aka, AU8YOG) touches turns to crap."
    --citizens of alt.obituaries--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Kenny McCormack on Wed Aug 16 17:36:11 2023
    [email protected] (Kenny McCormack) writes:
    (In Linux)
    I need to be able to change the "controlling terminal" of an arbitrary >process. I have read the doc for the ioctl TIOCSCTTY, but as far as I can >tell, that only works for the calling process. Also, it seems to have some >(IMHO) weird limitations. So, Q1: Is there any other system call for this?

    Note: I note that a lot of the "classic Unix" calls in this general area >(process/session/controlling tty stuff) are specifically only able to
    affect the calling process, but that Linux has expanded on this - often >allowing arbitrary processes to be affected.

    https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html

    11.1.3 The Controlling Terminal

    "Each process of a session that has a controlling terminal
    has the same controlling terminal"

    "A terminal may be the controlling terminal for at most one session."

    I believe there are security issues that would in general
    prevent one from willy-nilly changing the controlling terminal
    for an arbitrary process outside of the standard mechanisms like
    setsid.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Kenny McCormack on Wed Aug 16 18:41:01 2023
    On 2023-08-16, Kenny McCormack <[email protected]> wrote:
    (In Linux)
    I need to be able to change the "controlling terminal" of an arbitrary process. I have read the doc for the ioctl TIOCSCTTY, but as far as I can tell, that only works for the calling process. Also, it seems to have some (IMHO) weird limitations. So, Q1: Is there any other system call for this?

    I don't think there is any system call where you can do this to another process, passed as an argument.

    This would be something that would likely fall under the prctl system call.

    In an embedded situation where I control the kernel, I'd hack it into
    prctl.

    Do you have an X/Y problem here?

    Utilities like tmux and screen give processes a virtual terminal which
    is their controlling TTY, and can then detach and attach that session to
    a real TTY. Can that help in any way?

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @[email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to Scott Lurndal on Wed Aug 16 20:28:30 2023
    In article <fO7DM.428700$[email protected]>,
    Scott Lurndal <[email protected]> wrote:
    ...
    https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html

    11.1.3 The Controlling Terminal

    "Each process of a session that has a controlling terminal
    has the same controlling terminal"

    "A terminal may be the controlling terminal for at most one session."

    I believe there are security issues that would in general
    prevent one from willy-nilly changing the controlling terminal
    for an arbitrary process outside of the standard mechanisms like
    setsid.

    It looks like setsid(), followed by opening the desired terminal device,
    may solve my problem. Yes, I get it that this doesn't allow you to do it
    to an arbitrary process - it still has to be the process itself - but I
    think I can live with that.

    Q3: What happens if I follow the recipe above, but that terminal device
    that I open() is already the controlling terminal of some other session? I assume the open() doesn't fail, but that the calling process doesn't get a controlling terminal out of the deal. Is that right?

    P.S. No "XY problem" here, but the actual use case is way too complex to explain in a Usenet post.

    --
    Politics is show business for ugly people.

    Sports is politics for stupid people.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Kenny McCormack on Wed Aug 16 21:14:01 2023
    On 2023-08-16, Kenny McCormack <[email protected]> wrote:
    In article <fO7DM.428700$[email protected]>,
    Scott Lurndal <[email protected]> wrote:
    ...
    https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html

    11.1.3 The Controlling Terminal

    "Each process of a session that has a controlling terminal
    has the same controlling terminal"

    "A terminal may be the controlling terminal for at most one session."

    I believe there are security issues that would in general
    prevent one from willy-nilly changing the controlling terminal
    for an arbitrary process outside of the standard mechanisms like
    setsid.

    It looks like setsid(), followed by opening the desired terminal device,
    may solve my problem. Yes, I get it that this doesn't allow you to do it
    to an arbitrary process - it still has to be the process itself - but I
    think I can live with that.

    There are ways to make compiled programs do things!

    Using LD_PRELOAD you can force an executable to load shared libraries
    of your choice.

    This is famously used for overriding functions. But it could also
    introduce code that doesn't override anything.

    A shared library can have global initialization code that is run
    automatically, which you could use for manipulating the process'
    environment. I think that would be called before main.

    Your shared library could host a little server that listens for messages
    of your own design, which make the process do whatever you want at any
    point in its lifetime.

    This is why Linux mostly doesn't suffer from viruses; that's
    integrated as a feature.

    P.S. No "XY problem" here, but the actual use case is way too complex to explain in a Usenet post.

    n
    Ah, XY problem. :)


    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @[email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)