SEO

After doing a somewhat major upgrade on my system (including new
kernel), I can no longer get splitvt to work as a normal user.

I get this error:
pty_open() error: Permission denied

As root, it works fine.

What exactly has the wrong permissions, and how can I fix them permanently?
Thanks.

--
-WD

Will Dormann enlightened us with:
> What exactly has the wrong permissions, and how can I fix them
> permanently?

Run 'strace splitvt' and see which system call returns the 'permission
denied' error. Then you can easily see what was being opened.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?

Sybren Stuvel wrote:
> Will Dormann enlightened us with:
>
>>What exactly has the wrong permissions, and how can I fix them
>>permanently?
>
>
> Run 'strace splitvt' and see which system call returns the 'permission
> denied' error. Then you can easily see what was being opened.

I get the following:
stat64("/dev/ptya0", {st_mode=S_IFCHR|0733, st_rdev=makedev(2, 176),
....}) = 0
rt_sigaction(SIGALRM, {0x804a681, [ALRM], SA_RESTORER|SA_RESTART,
0x40061f98}, {SIG_DFL}, 8) = 0
alarm(2) = 0
open("/dev/ptya0", O_RDWR) = -1 EACCES (Permission denied)
alarm(0) = 2
alarm(2) = 0
open("/dev/ptya1", O_RDWR) = -1 EACCES (Permission denied)
alarm(0) = 2
alarm(2) = 0
open("/dev/ptya2", O_RDWR) = -1 EACCES (Permission denied)
alarm(0) = 2
alarm(2) = 0
....
And it keeps going for all the various /dev/pty* entries.


When I look at the /dev/pty items, I see:
lr-xr-xr-x 1 root root 8 Sep 25 11:13 /dev/ptya0 ->
pty/m176
lr-xr-xr-x 1 root root 8 Sep 25 11:13 /dev/ptya1 ->
pty/m177
lr-xr-xr-x 1 root root 8 Sep 25 11:13 /dev/ptya2 ->
pty/m178


The targets of the symlinks have write access, but the symlinks
themselves do not. chmod +w doesn't seem to help, either.

Any ideas?

Thanks.
--
-WD

Will Dormann enlightened us with:
> open("/dev/ptya0", O_RDWR) = -1 EACCES (Permission denied)
> ...
> And it keeps going for all the various /dev/pty* entries.

Hmm... I'll emerge splitvt and see if it works on my box.

[...]

Ok, done. I see the origin of the error as well. Read the manual page
again, and search for 'root':

splitvt can be made set-uid root. splitvt will reset its
user id to that of the person running it, just before it
exec()'s the shell under the window. The splitvt process
remains with root permissions, and will change ownership of the
pseudo terminals to that of the person running splitvt, and
then reset it to root when the window is closed.

SPLITVT IS NOT GUARANTEED TO BE A SAFE SET-UID PROGRAM!

I have done all I know to keep splitvt a safely usable set-uid
program, but I do not know everything, and am not responsible
for any security weaknesses splitvt might posess.

So if you want it to be usable for mortal users, and you're aware of
the risks involved, do 'chmod u+s $(which splitvt)' and you're set.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?

Sybren Stuvel wrote:
> Will Dormann enlightened us with:
>
>>open("/dev/ptya0", O_RDWR) = -1 EACCES (Permission denied)
>>...
>>And it keeps going for all the various /dev/pty* entries.
>
>
> Hmm... I'll emerge splitvt and see if it works on my box.

I talked to the program author, and he just made a new version that does
not have this problem:
http://www.devolution.com/~slouken/p...t-1.6.5.tar.gz


--
-WD

Will Dormann enlightened us with:
> I talked to the program author, and he just made a new version that
> does not have this problem:

Nice

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?