Re: runit: run process in a tty

2020-10-17 Thread Jonathan de Boyne Pollard

Kian Kasad:


Unable to open file: /dev/tty2: Operation not permitted.



Operating systems do a whole bunch of stuff when connecting user 
programs to terminals, including changing the permissions of the 
terminal device file to allow the logged-in user access.  If you check 
the terminal device file of a terminal where you have actually logged 
in, you will find that it is owned by you, and that the device files of 
terminals where you have not logged in are owned by the superuser.  This 
is one of several things that the login process does.


Taking ly's supplied systemd service unit and converting it using the 
nosh toolset's convert-systemd-units command 
(http://jdebp.uk./Softwares/nosh/guide/commands/convert-systemd-units.xml), 
one obtains the following, which demonstrates that there are extra steps 
involved and provides at least a pointer to how a "run" script for a 
runit service should be constructed.



% convert-systemd-units --no-systemd-quirks ./ly.service
convert-systemd-units: WARNING: ./ly.service: Unused setting: [install] alias = 
display-manager.service
%
% system-control print-service-scripts ./ly
start:#!/bin/nosh
start:#Start file generated from ./ly.service
start:true
stop:#!/bin/nosh
stop:#Stop file generated from ./ly.service
stop:true
run:#!/bin/nosh
run:#Run file generated from ./ly.service
run:#TUI display manager
run:vc-get-tty /dev/tty2
run:open-controlling-tty --revoke
run:vc-reset-tty --hard-reset
run:/usr/bin/ly
restart:#!/bin/sh
restart:#Restart file generated from ./ly.service
restart:exec true# ignore script arguments
%


Notice how the service invokes the open-controlling-tty program 
(http://jdebp.uk./Softwares/nosh/guide/commands/open-controlling-tty.xml) 
to open the terminal device file as standard I/O and to make it the 
service's controlling terminal.  It knows what terminal device because 
that has been set up by the vc-get-tty program 
(http://jdebp.uk./Softwares/nosh/guide/commands/vc-get-tty.xml) which 
was passed the name "/dev/tty2".


Notice also how the service runs the "ly" program as the superuser.  It 
does not drop privileges by switching to an unprivileged account.


Furthermore, notice that there are two separate places where one tells 
"ly" what terminal to use: in the service definition, as here, and in 
the program's own configuration file.




Re: runit: run process in a tty

2020-10-16 Thread Érico Nogueira
On Fri Oct 16, 2020 at 2:35 PM -03, Kian Kasad wrote:
> I'm trying to have a runit service spawn `/usr/bin/ly` in a certain tty
> (tty2). I've tried redirecting std{in,out,err} to the tty:
>
> exec /usr/bin/ly /dev/tty2 2>&1
>
> but this didn't work.
>

As far as I know, ly wants to be explicitly configured for a certain
tty, instead of supporting being launched anywhere. Even then, it might
still require quite a bit of work to function properly.

You can see a service for it in a PR for Void Linux [1]. For anyone
curious, ly is a TUI display manager [2].

- [1] 
https://github.com/void-linux/void-packages/pull/24038/files#diff-cbcda52b1a625e2c6b384056d5fba09297ffdf613786fe00b8c23c209bf3d7d7
- [2] https://github.com/nullgemm/ly

> I tried the openvt(1) program, which has a flag `-e` to exec the program
> instead of forking it:

I don't know anything about openvt, unfortunately.


runit: run process in a tty

2020-10-16 Thread Kian Kasad
I'm trying to have a runit service spawn `/usr/bin/ly` in a certain tty
(tty2). I've tried redirecting std{in,out,err} to the tty:

exec /usr/bin/ly /dev/tty2 2>&1

but this didn't work.

I tried the openvt(1) program, which has a flag `-e` to exec the program
instead of forking it:

openvt -ec 2 /usr/bin/ly

This returned an error:
Unable to open file: /dev/tty2: Operation not permitted.

However, openvt(1) works when using the `-w` (wait) flag instead of `-e`
(exec). So my questions are:
- Does anyone know why this happens?
- Is there a better way to spawn a process on a certain tty with runit?

Thanks,
Kian Kasad


signature.asc
Description: PGP signature