[Komport-devel] lock files, setuid, etc...

[Mike S. <mi...@sh...>]

I've started working on the new KomportLock class right now. I would like this 
to be able to lock the port in a way that's compatible with other serial port 
programs such as uucp, ppp, minicom, fax, etc...

This means using lock files, as ugly as that may be.

The lock file should be /var/lock/LCK..<device>, such as /var/lock/LCK..ttyS0, 
and should contain the process ID number of the owner process.

I've always thought this was dumb, but it's the way the other programs work so 
I guess we have little choice.

My question is regarding setuid. You may already be aware that /var/lock is 
not world writable, the way other programs get around this is by being setuid 
0 (root). Historically, the need to run setruid 0 has opened up numerous 
exploits in minicom and others.

I can see four options so far:

1) We run setuid 0 like minicom and the others. Although, this is the simplest 
in term of effort, I don't like at all because it's a complex program (Qt GUI 
etc...) and would be impossible to make it reasonably secure from local 
exploits.

2) We develop an external lock file helper or daemon that runs setuid 0. This 
program would be very simple and relatively easy to make secure. The program 
would have only two functions, obtain a lock file, and release a lock file.

3) We use the existing sudo system for running either komport itself, or an 
external helper.

4) Forget about compatibility with ancient serial port programs and develop a 
new modern locking system using semaphores. Unless others would adopt this 
same protocol, then komport will only be able to lock against other instances 
of komport. For my needs this would be fine since komport is the only thing I 
run against my serial port devices.

I vote #4 although I know that would get a lot of complaints, but it would  
bring the issue of using those out dated lock files to the front burner. 
There aer a lot of problems with those lock files, not only the ones I've 
pointed out regarding setuid issues, but also the idea that the same device 
can have unlimited number of symlinks, for example, /dev/ttyS0 and 
/dev/modem.

I say it's high time we develop a new modernized protocol for locking serial 
devices. Anybody with me on that?

Mike Sharkey