Re: [Komport-devel] lock files, setuid, etc...
Status: Alpha
Brought to you by:
msharkey
From: Mike S. <mi...@sh...> - 2003-12-19 20:23:38
|
Sorry, I probably have not been describing the problem very clearly.....this is not a new problem, this has been a problem with un*x serial ports forever. The question is not if the user has write access to the /dev/ttyX device, but rather if someone else currently has the device open. The trouble is that the kernel allows multiple programs to open the serial port at the same time, which, as a matter of principal, is the way it should be. However, the kernel should respect the open() with O_EXCL (exclusive) flag on the serial ports, but it does not. So there is no way to tell if you have exclusive access to the port, or on the other hand if someone else already has exclusive access to the port. The only way to know if to implement and obey a locking protocol.s The traditional locking protocol involves creating /var/lock/LCK..ttyX style lock files that you are responsible for testing for the presence or absence (or staleness) of. It's ugly and requires setuid 0. Not to mention it's not always accurate because it does not take into account symlinks to the same device. Basically, it stinks. In other words, It's a lot of effort to implement something that does not even work very well. <sigh...> Basically, what I just put into CVS implements semaphore locking using System-V derived ipc (Inter Process Communication). It's very simple, does not require anybody to be setuid 0, and it take into account symlinks to the device file. It is really the way to go for this kind of situation......However, the down side is that it does not respect the old style of locks that minicom and friends use, so it will only handle the case of running two concurrent komport programs trying to access the same port. Which actually is probably the common case, as I've been doing that a lot myself inadvertently. As far as port (/dev/ttyX file) permissions go, it's not nessesary to be root (uid 0) to access /dev/ttyX. You can simply create a "serialuser" (or whatever) group in /etc/group and then change the group ownership of the serial device, like; "chgrp serialuser /dev/ttyX". Afterwards, then just add users who you wish to have access to /dev/ttyX to the "serialuser" group. Regards, --Mike On Friday 19 December 2003 02:45 pm, Steven Kreuzer wrote: > 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 > > ------------------------------------------------------- > 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 |