Thread: [Komport-devel] CVS update
Status: Alpha
Brought to you by:
msharkey
Menu
▾
▴
komport-devel
|
From: Mark <mb...@ya...> - 2003-12-02 07:56:02
|
As of earlier today, Komport is in the SourceForge CVS repository. For the source code checkout the module 'src' as previous mentioned. It has the source of the last release and ready for any changes. The modules for distribution are next on my list which hopefully will take almost no time. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca |
|
From: Mike S. <mi...@sh...> - 2003-12-02 12:31:25
|
Cool! I'll be checking out later today and I'll report back how it goes. --Mike On Tuesday 02 December 2003 02:56 am, Mark wrote: > As of earlier today, Komport is in the SourceForge CVS repository. For the > source code checkout the module 'src' as previous mentioned. It has the > source of the last release and ready for any changes. > > The modules for distribution are next on my list which hopefully will take > almost no time. > > ______________________________________________________________________ > Post your free ad now! http://personals.yahoo.ca > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
|
From: Mike S. <mi...@sh...> - 2003-12-02 17:45:27
|
Hi guys, Here's komport 0.5.8 pre-0.6: ftp://sharkey.servebeer.com/pub/komport/komport-0.5.8.tar.gz Please get it and try doing a build. KomportView is almost completely rewritten so I want to see if there are any major problems before we release 0.6. Please reply to the list with any trouble building or any strangeness that you think should be addressed before 0.6 You should see much smoother scrolling, and much smoother text selection. Also, overall there should be an improvement in screen drawing speed. There is still a bit of an issue with the scroll bars encroaching on the viewport area that I already know about and I will address that before 0.6 --Mike |
|
From: Mike S. <mi...@sh...> - 2003-12-02 19:37:57
|
Hi all, I would like everyone (including myself) to be begin to be able to work directly from CVS. I'm just wondering how would be the best way to get the latest source (0.5.8pre0.6) into CVS. I tagged 0.5.8 (I later saw Mark had already tagged it - sorry Mark - I'll leave such things to you in the future). Should I just merge my changes locally then commit them, or perhaps we should do a branch or what? Anyway, consider 0.5.8 to be the latest source and I will make no further changes until after we get the latest changes into CVS. --Mike |
|
From: Mike S. <mi...@sh...> - 2003-12-02 19:45:14
|
Sorry, I meant that I tagged 0.5.3 *not* 0.5.8 --Mike On Sunday 30 November 2003 05:31 am, Mike Sharkey wrote: > I tagged 0.5.8 (I later saw Mark had already tagged > it - sorry Mark - I'll leave such things to you in the future). |
|
From: Mike S. <mi...@sh...> - 2003-12-03 01:19:58
|
Hi All, I think I've successfully committed the changes to bring the repository up to the latest 0.5.9 version (I had to make a few bug fixes after 0.5.8). People should now be able to build the latest from the repository. Let me know how it goes, please. Everyone involved in the project should have write access to the repository. Please let me know if you need an adjustment to your privileges. Mark, I'm hoping you will keep everyone in line with respect to repository discipline. Maybe you could draft a set of basic guidelines. What I would like is to be able to have tags or some mechanism to get to the last buildable and runnable version. Anyone else have any input on repository discipline? Should we have a "stable" and "unstable" branch perhaps? I don't know, I'm asking the CVS experts. In any case, I will be working from CVS from now on. Any of you who are interested in doing some KDE/C++ programming, please by all means feel free. :) A few house keeping chores and some TODO items I think we should get done over the next little while: * Put all string constants into one header file to simplify localization as per Robert's earlier suggestion. * Update the ChangeLog, AUTHORS, README, TODO files to contain useful information..... * Get package files (.spec, etc...) into repository. I'll work on the TODO list next, as I think that's my biggest task right now is to prioritize coding items for the 0.6 release. Well, it's really looking good, thanks everyone for helping out! Cheers all! --Mike |
|
From: Mike S. <mi...@sh...> - 2003-12-03 14:00:04
|
I was able to make a few changes this morning and committed them to the repository. I've added a file called komportstrings.h which contains all of the application i18n text strings for localization. The strings I've done so far are the menus, tootips, and status text. I have not yet done the settings dialog as I need to revise the settings form first. Also I've fixed some scrolling issues, vertical scroll bar now scrolls by line rather than by pixel, and pages by one screen. Also history limit is now working properly again. Printing the screen was broken in 0.5.8 and is now fixed since 0.5.9. I did a little optimization in the KomportCell cell class, both for memory consumption and performance. Please everyone have a look at the latest TODO file (for 0.6) and let everyone know if you have anything to add, subtract, modify, or discuss. Enjoy! --Mike |
|
From: Mike S. <mi...@sh...> - 2003-12-03 14:46:04
|
Is there anyone on the list who is artistically inclined by any chance? Perhaps if you are, you might come up with a graphic to use as an application icon. When it comes to artistic creativity, let's just say, it's best that I don't do it. Should I maybe post a "help wanted" ad on sf? --Mike |
|
From: Steven K. <skr...@f2...> - 2003-12-03 15:22:48
|
I'm not quite sure how localization works and if it is done automatically, but if you need someone to help translate to German, let me know. > I was able to make a few changes this morning and committed them to the > repository. > > I've added a file called komportstrings.h which contains all of the > application i18n text strings for localization. The strings I've done so > far > are the menus, tootips, and status text. I have not yet done the settings > dialog as I need to revise the settings form first. > > Also I've fixed some scrolling issues, vertical scroll bar now scrolls by > line > rather than by pixel, and pages by one screen. Also history limit is now > working properly again. > > Printing the screen was broken in 0.5.8 and is now fixed since 0.5.9. > > I did a little optimization in the KomportCell cell class, both for memory > consumption and performance. > > Please everyone have a look at the latest TODO file (for 0.6) and let > everyone > know if you have anything to add, subtract, modify, or discuss. > > Enjoy! > > --Mike > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel > |
|
From: Mark <m....@sh...> - 2003-12-04 08:37:06
|
To start this discussion regarding CVS usage and tagging of files, my
experience from some experienced individuals is to keep commits specific
to a change if possible. Searching the comments can help find the
change or future issues. (Radical rewrites of course do not count and
might be a reason to branch at some point?) The key they feel is to
make sure that whatever is in CVS compiles. (Again another case for a
branch of the code in CVS if/when necessary.)
My goal at some point is to get the tagging of every release made and
see whatever else I can do with what SF allows. (Already behind with
0.5.9, I know) My thought on releasing an 'unstable' version is to hold
off for right now. If someone is interested, they can checkout from
anonymous CVS the latest which may or may not work ("unstable").
As you may or may not have noticed, the packaging source has not been
added to CVS. If someone could send me at least some of the files to
have a base with, I will tag appropriately to move on. (Thought I sent
an e-mail to Steven but might have been bounced?)
Mark
Mike Sharkey wrote:
> Hi All,
>
> I think I've successfully committed the changes to bring the repository up to
> the latest 0.5.9 version (I had to make a few bug fixes after 0.5.8). People
> should now be able to build the latest from the repository.
>
> Let me know how it goes, please.
>
> Everyone involved in the project should have write access to the repository.
> Please let me know if you need an adjustment to your privileges.
>
> Mark, I'm hoping you will keep everyone in line with respect to repository
> discipline. Maybe you could draft a set of basic guidelines.
>
> What I would like is to be able to have tags or some mechanism to get to the
> last buildable and runnable version. Anyone else have any input on repository
> discipline?
>
> Should we have a "stable" and "unstable" branch perhaps? I don't know, I'm
> asking the CVS experts.
>
> In any case, I will be working from CVS from now on. Any of you who are
> interested in doing some KDE/C++ programming, please by all means feel free.
> :)
>
> A few house keeping chores and some TODO items I think we should get done over
> the next little while:
>
> * Put all string constants into one header file to simplify localization as
> per Robert's earlier suggestion.
>
> * Update the ChangeLog, AUTHORS, README, TODO files to contain useful
> information.....
>
> * Get package files (.spec, etc...) into repository.
>
> I'll work on the TODO list next, as I think that's my biggest task right now
> is to prioritize coding items for the 0.6 release.
>
> Well, it's really looking good, thanks everyone for helping out!
>
> Cheers all!
>
> --Mike
|
|
From: Mike S. <mi...@sh...> - 2003-12-04 17:36:35
|
Good points, Mark. When I have a moment, I'll make sure we can checkout and
build from CVS, I think everything that's currently checked in should build.
Just a heads up that the code in CVS is now newer than 0.5.9.
Next time I have some time to work on Komport, I will be addressing the high
priority TODO items roughly in the order they are listed. This will include
getting the remaining strings into komportstrings.h so we can start with
translations.
I've been doing a little thinking this morning about text selection. First, I
would like to add a text selection mode toggle that toggles between selecting
rectangular area (the current way), and selecting in line mode (ala xterm).
First, are there any thoughts about that?
Secondly, I would like to add a menu item Edit->Select_All, but I have a few
questions about that. Should Select_All only select the text in the viewport
bounds, or should it select the viewport and also include the history buffer.
Or should there be two separate select-all functions, one for viewport, and
one for history? If so, should the Select_All_History function also select
the viewport text or only the text which has scrolled into the history?
Hmmmm.....I may need to consult with Mr Red Cap again.....
On Thursday 04 December 2003 03:32 am, Mark wrote:
> To start this discussion regarding CVS usage and tagging of files, my
> experience from some experienced individuals is to keep commits specific
> to a change if possible. Searching the comments can help find the
> change or future issues. (Radical rewrites of course do not count and
> might be a reason to branch at some point?) The key they feel is to
> make sure that whatever is in CVS compiles. (Again another case for a
> branch of the code in CVS if/when necessary.)
>
> My goal at some point is to get the tagging of every release made and
> see whatever else I can do with what SF allows. (Already behind with
> 0.5.9, I know) My thought on releasing an 'unstable' version is to hold
> off for right now. If someone is interested, they can checkout from
> anonymous CVS the latest which may or may not work ("unstable").
>
> As you may or may not have noticed, the packaging source has not been
> added to CVS. If someone could send me at least some of the files to
> have a base with, I will tag appropriately to move on. (Thought I sent
> an e-mail to Steven but might have been bounced?)
>
> Mark
>
> Mike Sharkey wrote:
> > Hi All,
> >
> > I think I've successfully committed the changes to bring the repository
> > up to the latest 0.5.9 version (I had to make a few bug fixes after
> > 0.5.8). People should now be able to build the latest from the
> > repository.
> >
> > Let me know how it goes, please.
> >
> > Everyone involved in the project should have write access to the
> > repository. Please let me know if you need an adjustment to your
> > privileges.
> >
> > Mark, I'm hoping you will keep everyone in line with respect to
> > repository discipline. Maybe you could draft a set of basic guidelines.
> >
> > What I would like is to be able to have tags or some mechanism to get to
> > the last buildable and runnable version. Anyone else have any input on
> > repository discipline?
> >
> > Should we have a "stable" and "unstable" branch perhaps? I don't know,
> > I'm asking the CVS experts.
> >
> > In any case, I will be working from CVS from now on. Any of you who are
> > interested in doing some KDE/C++ programming, please by all means feel
> > free.
> >
> > :)
> >
> > A few house keeping chores and some TODO items I think we should get done
> > over the next little while:
> >
> > * Put all string constants into one header file to simplify localization
> > as per Robert's earlier suggestion.
> >
> > * Update the ChangeLog, AUTHORS, README, TODO files to contain useful
> > information.....
> >
> > * Get package files (.spec, etc...) into repository.
> >
> > I'll work on the TODO list next, as I think that's my biggest task right
> > now is to prioritize coding items for the 0.6 release.
> >
> > Well, it's really looking good, thanks everyone for helping out!
> >
> > Cheers all!
> >
> > --Mike
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Komport-devel mailing list
> Kom...@li...
> https://lists.sourceforge.net/lists/listinfo/komport-devel
|
|
From: Mike S. <mi...@sh...> - 2003-12-13 13:59:45
|
sharkey.servebeer.com was offline during about a 12 hour local power interruption. Our backup power generators struggled valiantly to save the data processing center from going offline......for about 15 minutes.....at which time they scummed to the overwhelming load of the mega machines which occupy the sprawling data processing center. :) Service has now been restored....sorry for any trouble it may have caused. ---Management sharkey.servebeer.com |
|
From: Mike S. <mi...@sh...> - 2003-12-15 22:49:56
|
....Sorry guys if you've been trying to access host96. Since the power failure several days ago, host96 was acting up and now finally quit due to a power supply failure, and main board failure....I don't know which failed first and presumably caused the other to fail, but I'm assuming the power supply was the first to fail due to the recent power fluctuations....but who really knows...... In any case, I've ordered a new motherboard (TYAN S2466 TIGER MPX), this is not a cheap main board. Hopefully the CPUs are still good, because if not, this is gonna be a really expensive failure. Meanwhile host96 is up and limping with a new 2GHz Celeron main board with 1GB of ram. All hard discs are okay, and any work you have there should still be okay. I should have the new dual AMD Athlon (TYAN TIGER) board in about 3-4 days, after which I will be installing the new 2GHz Celeron board into sharkey.servebeer.com to replace the aging but very reliable Tyan Tomcat Dual P233 board. --Management sharkey.servebeer.com |
|
From: Mike S. <mi...@sh...> - 2003-12-15 23:50:04
|
By the way, this 2GHz Celeron feels like about 1/4 of the speed of the dual AMD Athlon, you can really feel the difference in the GUI, and compile time is quite noticeably slower. :( --Mike On Tuesday 16 December 2003 05:50 am, Mike Sharkey wrote: > ....Sorry guys if you've been trying to access host96. Since the power > failure several days ago, host96 was acting up and now finally quit due to > a power supply failure, and main board failure....I don't know which failed > first and presumably caused the other to fail, but I'm assuming the power > supply was the first to fail due to the recent power fluctuations....but > who really knows...... > > In any case, I've ordered a new motherboard (TYAN S2466 TIGER MPX), this is > not a cheap main board. Hopefully the CPUs are still good, because if not, > this is gonna be a really expensive failure. Meanwhile host96 is up and > limping with a new 2GHz Celeron main board with 1GB of ram. All hard discs > are okay, and any work you have there should still be okay. > > I should have the new dual AMD Athlon (TYAN TIGER) board in about 3-4 days, > after which I will be installing the new 2GHz Celeron board into > sharkey.servebeer.com to replace the aging but very reliable Tyan Tomcat > Dual P233 board. > > --Management > sharkey.servebeer.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
|
From: Steven K. <skr...@f2...> - 2003-12-16 02:07:50
|
Do you have a backup solution on host96, or should we all take care of our own stuff? SK On Tue, 2003-12-16 at 05:50, Mike Sharkey wrote: > ....Sorry guys if you've been trying to access host96. Since the power failure > several days ago, host96 was acting up and now finally quit due to a power > supply failure, and main board failure....I don't know which failed first and > presumably caused the other to fail, but I'm assuming the power supply was > the first to fail due to the recent power fluctuations....but who really > knows...... > > In any case, I've ordered a new motherboard (TYAN S2466 TIGER MPX), this is > not a cheap main board. Hopefully the CPUs are still good, because if not, > this is gonna be a really expensive failure. Meanwhile host96 is up and > limping with a new 2GHz Celeron main board with 1GB of ram. All hard discs > are okay, and any work you have there should still be okay. > > I should have the new dual AMD Athlon (TYAN TIGER) board in about 3-4 days, > after which I will be installing the new 2GHz Celeron board into > sharkey.servebeer.com to replace the aging but very reliable Tyan Tomcat Dual > P233 board. > > --Management > sharkey.servebeer.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel > |
|
From: Mike S. <mi...@sh...> - 2003-12-16 03:17:07
|
Yeah, Steven, It's a very good point, and it's something I've been trying to ignore for far too long, yet I've allowed myself to loose sleep over it at the same time. Not just for Komport, but there are a few other projects (see http://sharkey.servebeer.com/~michael and there are also some not listed there) whose only existence on earth is on either sharkey.servebeer.com and/or host96. Actually (off topic), now that I'm mentioning those other projects, I'm hoping that some of your guys might want to help on some of those other projects next, but that's for another discussion at another time, we need to get Komport in the bag first...... Currently I do about a monthly backup on CD of projects and important things. I don't feel that it's enough but it's all I really have the capacity for, both in terms of time and machinery. I try to at least regularly mirror important stuff between at least two machines at all times in case of a hard drive failure. But certainly I must admit that it is far from ideal, and there is unquestionably room for improvement. I've been thinking about a mag tape. I have not looked into mag tape for probably about 6-8 years so any input would be welcome. The last mag tape drive I had was on a 368DX and it was a SCSI tape drive capable of 100MB of backup per tape. I know they have come a long way since then. :) In any case, with respect to Komport, I think we should be sure to try and keep the most recent stuff checked into the repository at SourceForge for the time being. Thanks Steven for bringing this to the front burner. Oh, and Cheers All! :) Hope you all are having as nice of a lead in to Christmas as I am! :) --Mike On Monday 15 December 2003 09:07 pm, Steven Kreuzer wrote: > Do you have a backup solution on host96, or should we all take care of > our own stuff? > > SK > > On Tue, 2003-12-16 at 05:50, Mike Sharkey wrote: > > ....Sorry guys if you've been trying to access host96. Since the power > > failure several days ago, host96 was acting up and now finally quit due > > to a power supply failure, and main board failure....I don't know which > > failed first and presumably caused the other to fail, but I'm assuming > > the power supply was the first to fail due to the recent power > > fluctuations....but who really knows...... > > > > In any case, I've ordered a new motherboard (TYAN S2466 TIGER MPX), this > > is not a cheap main board. Hopefully the CPUs are still good, because if > > not, this is gonna be a really expensive failure. Meanwhile host96 is up > > and limping with a new 2GHz Celeron main board with 1GB of ram. All hard > > discs are okay, and any work you have there should still be okay. > > > > I should have the new dual AMD Athlon (TYAN TIGER) board in about 3-4 > > days, after which I will be installing the new 2GHz Celeron board into > > sharkey.servebeer.com to replace the aging but very reliable Tyan Tomcat > > Dual P233 board. > > > > --Management > > sharkey.servebeer.com > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ > > _______________________________________________ > > Komport-devel mailing list > > Kom...@li... > > https://lists.sourceforge.net/lists/listinfo/komport-devel > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Komport-devel mailing list > Kom...@li... > https://lists.sourceforge.net/lists/listinfo/komport-devel |
|
From: Mike S. <mi...@sh...> - 2003-12-16 04:17:19
|
I have a very very small complaint. How come nobody is logging any Komport bugs on SourceForge except for me? :) Every time I try to use Komport, I see bugs, many of them. Am I the only one that sees them? Please don't assume I've seen them, or let alone, assume that I've logged them, I am probably the worst person in the world to count on for logging bugs. Also, more importantly, I would like to know how other people feel about the priority of particular bugs........So have no shame Man....complain!! Man! Get it off your chest!! That nagging, that perpetually gnawing feeling, that, "why won't that guy fix that damn thing?!?!?!?" feeling. :) Pick a bug and assign it to me on SourceForge. I will fix it. PS. Brick Amber Beer Rocks! :) (If you're in Canada you know what I'm talking about -- stubbies --, otherwise sorry ignore it). --Mike |
|
From: Mike S. <mi...@sh...> - 2003-12-18 18:00:09
|
Hi All, Just not let everyone interested to know that host96 is back and is operating at 100% capacity with a new TYAN Tiger MPX S2466 (Rev 1.20) main board. The good news is that the old CPUs and RAM did not get cooked in the previous melt down. Host96 seems to be running really nicely so far. I'll be running sensor monitors from now on to monitor CPU temperature, fan speed, and power supply voltage, and will email me if any of those fall out of line. Just a small note on the internal network while I'm at it, I've changed the internal network from primrose.net to sharkey.serevbeer.com, thus host96.primrose.net becomes host96.sharkey.servebeer.com. <off topic> Anybody using any tape drives for backup? Any good or bad comments about particular vendors, or media? Okay, now that the painful episode is over, I'm back to work on komport....... Regards, Mike Sharkey |
|
From: Mike S. <mi...@sh...> - 2003-12-19 14:38:30
|
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 |
|
From: Mike S. <mi...@sh...> - 2003-12-19 17:58:10
|
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 |
|
From: Steven K. <skr...@f2...> - 2003-12-19 19:45:23
|
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 > |
|
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 |
Thanks for helping keep SourceForge clean.
X