Re: s6 xinit replacement?
On 5/28/22 12:15 PM, Dallin Dahl wrote:
> It turns out I had the same issue as Rio, since my login shell was still
> controlling my terminal. If I run:
>
> exec s6-setsid X :3 vt3
>
> while logged into tty3, I get an X display. However, I still can't
> seem to get it to work with s6-svscan. If I exec into s6-svscan from
> my login shell, svscan then controls the tty. If I exec into s6-setsid
> s6-svscan, it still seems attached to the tty. I thought that maybe
> using the tiocnotty ioctl call would free the tty for X to pick up,
> so I wrote the following wrapper program:
>
> #include
> #include
> #include
> #include
>
> int main(int argc, char **argv) {
> int tty = open("/dev/tty", O_RDONLY);
This doesn't close the TTY. I don't know if that makes a difference.
> int res = ioctl(tty, TIOCNOTTY);
> if(!~res) perror("tiocnotty");
> argv++;
> execvp(*argv, argv);
> return 0;
> }
>
> and tried to exec into that before s6-svscan, both with and without
> s6-setsid. Unfortunately, the process immediately exits. I don't think
> it's my wrapper program, since I can run other programs with it without
> problems, and they do indeed show up in the output of ps aux without a
> controlling terminal.
>
> So I guess the new question is how can I free the tty after login,
> allowing X to open it and control it?
Have you tried redirecting all three standard fds elsewhere (/dev/null or a
file) when running s6-svscan? Possibly either s6-svscan or s6-supervise is doing
some fd manipulation that steals control of the TTY before X can get it. You
could also try running s6-supervise directly to narrow this down.
Regards,
Samuel
Re: s6 xinit replacement?
It turns out I had the same issue as Rio, since my login shell was still
controlling my terminal. If I run:
exec s6-setsid X :3 vt3
while logged into tty3, I get an X display. However, I still can't
seem to get it to work with s6-svscan. If I exec into s6-svscan from
my login shell, svscan then controls the tty. If I exec into s6-setsid
s6-svscan, it still seems attached to the tty. I thought that maybe
using the tiocnotty ioctl call would free the tty for X to pick up,
so I wrote the following wrapper program:
#include
#include
#include
#include
int main(int argc, char **argv) {
int tty = open("/dev/tty", O_RDONLY);
int res = ioctl(tty, TIOCNOTTY);
if(!~res) perror("tiocnotty");
argv++;
execvp(*argv, argv);
return 0;
}
and tried to exec into that before s6-svscan, both with and without
s6-setsid. Unfortunately, the process immediately exits. I don't think
it's my wrapper program, since I can run other programs with it without
problems, and they do indeed show up in the output of ps aux without a
controlling terminal.
So I guess the new question is how can I free the tty after login,
allowing X to open it and control it?
Thanks so much for your help!
--Dallin
Re: Unprivileged Shutdown?
I have been using simple privilege escalation to poweroff the machine, but looking through the source code for s6-linux-init-shutdownd and friends, it appears the only constraint on interacting with the daemon is the permissions on run-image/service/s6-linux-init-shutdownd/fifo. The default appears to be: 600 root root I've changed it on my system to be: 620 root power and added my user to the power group. This seems like the cleanest way to implement unprivileged poweroff/reboot, but I'm concerned that it's not possible by default. Is there a better way, or is it just meant to be done manually? No, you are correct that it is the right mechanism. Allowing unprivileged shutdown is a dangerous operation and should only be done is very specific circumstances (i.e. when a normal user has complete seat and console access), so it's not the default and the mechanism is fairly hidden. If there's demand, I can probably write a s6-linux-init-shutdown-perms program in a future version that would let you specify the user/group allowed to shutdown, rather than having you manually tinker with the fifo. -- Laurent
