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

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

If you obtain the latest CVS sources, you will see that I've implemented ipc 
style semaphore locking in the KomportLock class.

If you now try  to run  two instances of komport on the same device  you will 
see how the second instance will be locked out from accessing the device. 
However this still does not resolve the issue when running another app such 
as minicom on the same device.

Still I feel that this current method is useful in that it handles the more 
common case of inadvertently attempting to access the same device from 
multiple instances of komport.

This also handles the symlink case (i.e. /dev/ttyS0 == /dev/modem) because 
ftok() uses the resolved  inode number in building the key used to select the 
semaphore, so you will get the same key from any symlinks which resolve to 
the same device file.

If you happen to get stuck with a dangling semaphore due to an abrupt program 
termination (signal 11 for example), then you have to use the ipc tools to 
remove the dangling semaphore (ipcs, and ipcrm).

Now, if we could just get everyone else to use this same protocol..... :)
 
Anyway, my feeling at this stage is that we leave it like this and just see 
what reaction we get. Or, in other words, when you're not sure what to do, do 
nothing.

Regards,

Mike


On Friday 19 December 2003 09:38 am, Mike Sharkey wrote:
> 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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Komport-devel mailing list
> Kom...@li...
> https://lists.sourceforge.net/lists/listinfo/komport-devel