Re: [help-gnubatch] gbch-xq

[John Collins (home)]

On 18/10/10 06:32, Jan Schampera wrote:

Todd Jackson wrote:

> gbch-xq: Warning! /home/tjackson/.gnubatch exists but is not readable!

Is it (for the RUID, you)?

 I'm pretty sure this is because this program is setuid gnubatch, but does anyone know a way to avoid having to do the xhost command (and disabling X security)?

This could be managed by separating the display access to RUID and doing the work using the permissions it gets from the SetUID bit. I don't know if this is that easy to do in the current code. Maybe Mr. Collins knows off from head (i.e. playing *UID switching for API access and user interface).

Sorry, no real help there.

Jan

I'm sorry but I don't know how to avoid having to do "xhost +" with a setuid gnubatch gbch-xq. If anyone finds out please let me know.

I preferred having gbch-xq do all the required operations directly - including the shared memory contents, don't forget that - rather than package up various shell commands or using the API.

The thing which forces it to stay setuid rather than opening files and then flipping back to RUID is the use of the message queue, access to which is restricted to the current EUID in each case.

I suppose it could wrap UID switches round every message queue operation. Originally I had it use semaphores as well which would make it even worse.

In the next "real soon now" version I've dumped message queues in favour of UNIX domain sockets which have the additional advantage you can "select" for them at the same time as other sockets and don't have to rely on signals and/or a separate process to catch TCP packets and convert them into message queue messages.

The messages about the .gnubatch file are probably because you've got a 700 permission home directory and it can't be read with the setuid gnubatch process.

Unfortunately when you try to access a file which doesn't exist and you wouldn't have permission to access if it did exist, particularly because you don't have search permission on the path to it, kernels aren't consistent about which error they report first.

I suppose it ought to try with the real ID if it gets EACCES first time round as it isn't an error if it doesn't exist.

The original version which I wrote back in about 1990 had to contend with all sorts of funny Unixes (Unices?) which had all sorts of weird combinations of things you could and couldn't do with UIDs. Original ones lost the EUID for good once you'd flipped back to the RUID. Some ignored setuid if you were root. There were some that required you to do very fancy footwork to lose all traces of the original RUID. And there were dozens of different rules about who you could aim a "kill" at.

I've kept many of the #ifdefs for those kernels and the tests for them in the configure script.

--
John Collins address@hidden
Phone: +44 (0)1707 883174 Mobile: +44 (0)7958 387247 Work Phone: +44 (0)1707 886110
3 Mandeville Rise, Welwyn Garden City, Herts, AL8 7JT, UK