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

[Steven K. <skr...@f2...>]

Wouldn't it be easier to require the user running the program to have a
UID of 0

Simply checking if the user has read and write privilages on the device at
startup, and if not, display an error message and quit.

SK

> 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
>
>
>
> -------------------------------------------------------
> 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
>