Changing the "controlling terminal" of a process?

[Kenny McCormack]

(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--

[Scott Lurndal]

gaz...@shell.xmission.com (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.

[Kaz Kylheku]

On 2023-08-16, Kenny McCormack <gaz...@shell.xmission.com> 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: @Kazi...@mstdn.ca

[Kenny McCormack]

In article <fO7DM.428700$U3w1....@fx09.iad>,
Scott Lurndal <sl...@pacbell.net> 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.

[Kaz Kylheku]

On 2023-08-16, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> In article <fO7DM.428700$U3w1....@fx09.iad>,
> Scott Lurndal <sl...@pacbell.net> 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. :)