| View previous topic :: View next topic |
| Author |
Message |
Christoph Kobe
Guest
|
 Posted: Sun Oct 26, 2008 6:05 pm Post subject: Multiple programs accessing serial device |
 |
|
Hi,
I'm writing a program to cummunicate with a serial device. It's working, open("/dev/ttyS0", O_RDWR | O_NO_CTTY), write to it, read from it, everythings fine, but:
While my program is accessing /dev/ttyS0 other programs can do so as well, but I don't want that.
How can I block other programs from accessing /dev/ttyS0 while I want to use it? I looked in the glibc documentation and tried the O_SHLOCK and O_EXLOCK flags on open, but they don't seem to work on Linux (compile error).
Thank you for your answers,
Christoph |
|
| |
|
 Back to top |
Grant Edwards
Guest
|
| Posted: Sun Oct 26, 2008 6:49 pm Post subject: Re: Multiple programs accessing serial device |
|
|
On 2008-10-26, Christoph Kobe <christoph@kobenetz.de> wrote:
| Quote: | While my program is accessing /dev/ttyS0 other programs can do
so as well, but I don't want that.
How can I block other programs from accessing /dev/ttyS0 while
I want to use it?
|
Traditionally, programs controlled access to serial ports using
lockfiles.
--
Grant |
|
| |
|
| Back to top |
Christoph Kobe
Guest
|
| Posted: Sun Oct 26, 2008 9:41 pm Post subject: Re: Multiple programs accessing serial device |
|
|
On Sun, 26 Oct 2008 08:49:02 -0500
Grant Edwards <grante@visi.com> wrote:
| Quote: | Traditionally, programs controlled access to serial ports using
lockfiles.
|
What do you mean by lockfiles? I tried to lock the file ("/dev/ttyS0") using this:
----
int fd, return_value;
struct flock lockp;
fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
// some error checking here, but open works fine
lockp.l_type = F_WRLCK; // Also tried F_RDLCK
lockp.l_whence = SEEK_SET; // Also tried SEEK_CUR and SEEK_END
lockp.l_start = 0; // Also tried 1
lockp.l_len = 0; // Also tried 5
lockp.l_pid = 0; // This shouldn't matter anyway
return_value = fcntl(fd, F_SETLK, lockp);
----
But the call to fcntl fails, return_value gets set to -1, errno to 29 and perror tells me "Bad address".
What's wrong here? |
|
| |
|
| Back to top |
Grant Edwards
Guest
|
| Posted: Mon Oct 27, 2008 7:52 am Post subject: Re: Multiple programs accessing serial device |
|
|
On 2008-10-26, Christoph Kobe <christoph@kobenetz.de> wrote:
| Quote: | Grant Edwards <grante@visi.com> wrote:
Traditionally, programs controlled access to serial ports using
lockfiles.
What do you mean by lockfiles?
|
http://en.wikipedia.org/wiki/File_locking
http://www.linux.org/docs/ldp/howto/Serial-HOWTO-14.html
http://docs.freebsd.org/info/uucp/uucp.info.UUCP_Lock_Files.html
| Quote: | I tried to lock the file ("/dev/ttyS0") using this:
----
int fd, return_value;
struct flock lockp;
fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
// some error checking here, but open works fine
lockp.l_type = F_WRLCK; // Also tried F_RDLCK
lockp.l_whence = SEEK_SET; // Also tried SEEK_CUR and SEEK_END
lockp.l_start = 0; // Also tried 1
lockp.l_len = 0; // Also tried 5
lockp.l_pid = 0; // This shouldn't matter anyway
return_value = fcntl(fd, F_SETLK, lockp);
----
But the call to fcntl fails, return_value gets set to -1, errno to 29 and perror tells me "Bad address".
What's wrong here?
|
Dunno. I've never seen anybody try to lock a character device
file like that.
--
Grant |
|
| |
|
| Back to top |
Christoph Kobe
Guest
|
| Posted: Tue Oct 28, 2008 12:05 am Post subject: Re: Multiple programs accessing serial device |
|
|
On Sun, 26 Oct 2008 23:20:49 -0500
Grant Edwards <grante@visi.com> wrote:
| Quote: | http://en.wikipedia.org/wiki/File_locking
http://www.linux.org/docs/ldp/howto/Serial-HOWTO-14.html
http://docs.freebsd.org/info/uucp/uucp.info.UUCP_Lock_Files.html
|
I had read the Wikipedia article before, but reading through the
second article points out the main problem:
"Note that if a process insists on using a device that is locked,
it may ignore the lockfile and use the device anyway."
This is not what I am looking for. I want to restict access to
my programm and prevent other programs from using the device.
I dont't want to tell them "please don't use it", I want them
to get an "access denied".
Is that possible for /dev/ttyS0 ?
| Quote: | Dunno. I've never seen anybody try to lock a character device
file like that.
|
Maybe it's not supposed to be locked like that ?! |
|
| |
|
| Back to top |
Nate Eldredge
Guest
|
| Posted: Tue Oct 28, 2008 1:05 am Post subject: Re: Multiple programs accessing serial device |
|
|
Christoph Kobe <christoph@kobenetz.de> writes:
| Quote: | On Sun, 26 Oct 2008 23:20:49 -0500
Grant Edwards <grante@visi.com> wrote:
http://en.wikipedia.org/wiki/File_locking
http://www.linux.org/docs/ldp/howto/Serial-HOWTO-14.html
http://docs.freebsd.org/info/uucp/uucp.info.UUCP_Lock_Files.html
I had read the Wikipedia article before, but reading through the
second article points out the main problem:
"Note that if a process insists on using a device that is locked,
it may ignore the lockfile and use the device anyway."
This is not what I am looking for. I want to restict access to
my programm and prevent other programs from using the device.
I dont't want to tell them "please don't use it", I want them
to get an "access denied".
Is that possible for /dev/ttyS0 ?
|
It's possible there's a way, but I wouldn't be surprised if not.
This would run counter to the usual Unix philosophy that multiple
programs needing the same resource are expected to work it out among
themselves, rather than having the operating system give access to one
and deny the others. Locking mechanisms may be provided to facilitate
this, but usually they are advisory, and it's up to all parties to make
sure that they use those mechanisms consistently.
This has pros and cons. On the one hand it does allow a misbehaving
program to break things. But on the other hand, if you think about it,
having these sort of mandatory mechanisms leads to a kind of arms race.
Perhaps you have a misbehaving program that doesn't respect your locks,
so you want a locking mechanism that forbids everyone else from using
the resource. But now suppose some misbehaving program sets such a lock
on a file that you want to get at. So you need a way to override a
lock. But a misbehaving program might use such overrides
inappropriately. So now you need a lock that can't be overridden. Et
cetera, et cetera. (There are ways out of this trap, sort of, but they
tend not to be very nice.) The voluntary scheme also has the advantage
of being more flexible: the programmer can decide for herself what is
required, and it needn't conform to OS-imposed rules which might not be
appropriate in a certain case.
The sort of access control that Unix does offer is the permission
system. For instance, if you change the permissions on the device so
that only root (or whatever user your program runs as) can read or write
the device, then other users will be denied access, as you desire. It
won't lock out other programs running as root (or the same user), but
this goes to another tenet of Unix philosophy: each user is assumed to
be in control of the processes they run. If it's doing something you
don't want, but otherwise have permission to do, the OS won't stop it:
it's up to you to kill it, and not run it anymore until you've fixed it
(*). This applies also to root, who has permission to do almost
anything: root's processes can't restrict each other's behavior, and
it's up to the administrator to make sure they work in a desirable way,
and fix them if they don't.
So according to this philosophy, the way to handle your situation is
this: ensure that other users don't have access to the device in
question, and use the agreed-upon advisory locking mechanisms (lock
files in /var/lock in this case). If other programs you run are
well-behaved, they will respect this. If they aren't well-behaved, then
don't run them, or fix them so that they are. The OS might provide
tools to help you detect this situation and track down the offender, but
you shouldn't expect it to "save you from yourself".
Again, this philosopy has pros and cons, but it's pretty well ingrained
in Unix and in general you're not going to get very far trying to change
it.
So maybe you should think some more about why you want to do this, what
problem you're really trying to solve, and whether there is another
solution more in keeping with this philosophy.
| Quote: | Dunno. I've never seen anybody try to lock a character device
file like that.
Maybe it's not supposed to be locked like that ?!
|
Yeah, AFAIK the convention for locking devices is via creating device
files in /var/lock. flock()/fcntl() are for regular files. |
|
| |
|
| Back to top |
Grant Edwards
Guest
|
| Posted: Tue Oct 28, 2008 1:16 am Post subject: Re: Multiple programs accessing serial device |
|
|
On 2008-10-27, Christoph Kobe <christoph@kobenetz.de> wrote:
| Quote: | On Sun, 26 Oct 2008 23:20:49 -0500
Grant Edwards <grante@visi.com> wrote:
http://en.wikipedia.org/wiki/File_locking
http://www.linux.org/docs/ldp/howto/Serial-HOWTO-14.html
http://docs.freebsd.org/info/uucp/uucp.info.UUCP_Lock_Files.html
I had read the Wikipedia article before, but reading through the
second article points out the main problem:
"Note that if a process insists on using a device that is locked,
it may ignore the lockfile and use the device anyway."
This is not what I am looking for. I want to restict access to
my programm and prevent other programs from using the device.
I dont't want to tell them "please don't use it", I want them
to get an "access denied".
Is that possible for /dev/ttyS0 ?
|
From what I can tell by examining the source code for the tty
driver, it looks like you might want to try the TIOCEXCL ioctl.
--
Grant Edwards grante Yow! You were s'posed
at to laugh!
visi.com |
|
| |
|
| Back to top |
Grant Edwards
Guest
|
| Posted: Tue Oct 28, 2008 1:19 am Post subject: Re: Multiple programs accessing serial device |
|
|
On 2008-10-26, Christoph Kobe <christoph@kobenetz.de> wrote:
| Quote: |
I'm writing a program to cummunicate with a serial device.
It's working, open("/dev/ttyS0", O_RDWR | O_NO_CTTY), write to
it, read from it, everythings fine, but:
While my program is accessing /dev/ttyS0 other programs can do
so as well, but I don't want that.
How can I block other programs from accessing /dev/ttyS0 while
I want to use it? I looked in the glibc documentation and
tried the O_SHLOCK and O_EXLOCK flags on open, but they don't
seem to work on Linux (compile error).
|
I don't see either of those options on the open(2) man page.
--
Grant Edwards grante Yow! Do you like "TENDER
at VITTLES"?
visi.com |
|
| |
|
| Back to top |
Grant Edwards
Guest
|
| Posted: Tue Oct 28, 2008 1:26 am Post subject: Re: Multiple programs accessing serial device |
|
|
On 2008-10-27, Grant Edwards <grante@visi.com> wrote:
| Quote: | On 2008-10-27, Christoph Kobe <christoph@kobenetz.de> wrote:
"Note that if a process insists on using a device that is locked,
it may ignore the lockfile and use the device anyway."
This is not what I am looking for. I want to restict access to
my programm and prevent other programs from using the device.
I dont't want to tell them "please don't use it", I want them
to get an "access denied".
Is that possible for /dev/ttyS0 ?
From what I can tell by examining the source code for the tty
driver, it looks like you might want to try the TIOCEXCL ioctl.
|
NB: it looks like that "lock" is only enforced if the process
calling open() doesn't have the sys_admin capability.
--
Grant Edwards grante Yow! Sometime in 1993
at NANCY SINATRA will lead a
visi.com BLOODLESS COUP on GUAM!! |
|
| |
|
| Back to top |
Nate Eldredge
Guest
|
| Posted: Tue Oct 28, 2008 1:38 am Post subject: Re: Multiple programs accessing serial device |
|
|
Nate Eldredge <nate@vulcan.lan> writes:
| Quote: | The sort of access control that Unix does offer is the permission
system. For instance, if you change the permissions on the device so
that only root (or whatever user your program runs as) can read or write
the device, then other users will be denied access, as you desire. It
won't lock out other programs running as root (or the same user), but
this goes to another tenet of Unix philosophy: each user is assumed to
be in control of the processes they run. If it's doing something you
don't want, but otherwise have permission to do, the OS won't stop it:
it's up to you to kill it, and not run it anymore until you've fixed it
(*). This applies also to root, who has permission to do almost
anything: root's processes can't restrict each other's behavior, and
it's up to the administrator to make sure they work in a desirable way,
and fix them if they don't.
|
I left out my footnote:
(*) I think this owes something to Unix's origins as an environment for
programmers. Each user would ordinarily have the source to all their
own programs, and so could fix any undesired behavior at that level and
then recompile. By extension, the administrator would be expected to
have the complete source for the operating system and all system
programs. This idea loses something when you have closed-source
software and users (and admins) who aren't skilled programmers, and has
a lot to do with the close connection to this day between open-source
software and Unix-like operating systems. |
|
| |
|
| Back to top |
Christoph Kobe
Guest
|
| Posted: Wed Oct 29, 2008 6:10 pm Post subject: Re: Multiple programs accessing serial device |
|
|
On Mon, 27 Oct 2008 13:05:50 -0700
Nate Eldredge <nate@vulcan.lan> wrote:
| Quote: | Again, this philosopy has pros and cons, but it's pretty well ingrained
in Unix and in general you're not going to get very far trying to change
it.
So maybe you should think some more about why you want to do this, what
problem you're really trying to solve, and whether there is another
solution more in keeping with this philosophy.
(*) I think this owes something to Unix's origins as an environment for
programmers. Each user would ordinarily have the source to all their
own programs, and so could fix any undesired behavior at that level and
then recompile. By extension, the administrator would be expected to
have the complete source for the operating system and all system
programs. This idea loses something when you have closed-source
software and users (and admins) who aren't skilled programmers, and has
a lot to do with the close connection to this day between open-source
software and Unix-like operating systems.
|
Thanks for your explaination. I wans't quite aware of the philosophy
behind it. I have to admint that I don't really have a problem that
couldn't be solved with the lockfiles approach. I still have enough
control over the programs running on that linux box, so lockfiles will do
fine. Using file permissions for the device would also be convenient in
my case, since the program is not run by a user but as a daemon started
via crontab.
But on the other hand I'm coming from the windows-world where I see
little cooperation bewtween programs and where in some cases it's
necessary to exclude other programs run by the same user from acessing
the same device. So it turns out to me, that myquestion was rather about
the principle behind it, which is quite different for the two systems.
Thanks again,
Christoph |
|
| |
|
| Back to top |
Grant Edwards
Guest
|
| Posted: Wed Oct 29, 2008 6:35 pm Post subject: Re: Multiple programs accessing serial device |
|
|
On 2008-10-29, Christoph Kobe <christoph@kobenetz.de> wrote:
| Quote: | But on the other hand I'm coming from the windows-world where I see
little cooperation bewtween programs and where in some cases it's
necessary to exclude other programs run by the same user from acessing
the same device.
|
You should be able to do that under Unix by using the TIOCEXCL
ioctl.
--
Grant Edwards grante Yow! Here we are in America
at ... when do we collect
visi.com unemployment? |
|
| |
|
| Back to top |
Nate Eldredge
Guest
|
| Posted: Wed Oct 29, 2008 9:25 pm Post subject: Re: Multiple programs accessing serial device |
|
|
Christoph Kobe <christoph@kobenetz.de> writes:
| Quote: | On Mon, 27 Oct 2008 13:05:50 -0700
Nate Eldredge <nate@vulcan.lan> wrote:
Again, this philosopy has pros and cons, but it's pretty well ingrained
in Unix and in general you're not going to get very far trying to change
it.
So maybe you should think some more about why you want to do this, what
problem you're really trying to solve, and whether there is another
solution more in keeping with this philosophy.
(*) I think this owes something to Unix's origins as an environment for
programmers. Each user would ordinarily have the source to all their
own programs, and so could fix any undesired behavior at that level and
then recompile. By extension, the administrator would be expected to
have the complete source for the operating system and all system
programs. This idea loses something when you have closed-source
software and users (and admins) who aren't skilled programmers, and has
a lot to do with the close connection to this day between open-source
software and Unix-like operating systems.
Thanks for your explaination. I wans't quite aware of the philosophy
behind it. I have to admint that I don't really have a problem that
couldn't be solved with the lockfiles approach. I still have enough
control over the programs running on that linux box, so lockfiles will do
fine. Using file permissions for the device would also be convenient in
my case, since the program is not run by a user but as a daemon started
via crontab.
But on the other hand I'm coming from the windows-world where I see
little cooperation bewtween programs and where in some cases it's
necessary to exclude other programs run by the same user from acessing
the same device. So it turns out to me, that myquestion was rather about
the principle behind it, which is quite different for the two systems.
|
You're welcome. I recently had a conversation with a programmer with a
Windows background who was working on a project on Unix, which had
several instances of his program using the same file. He was amazed to
learn that Unix would allow more than one process to write to a file at
the same time. (I on the other hand remember being amazed when I found
that Windows would not.) So I had an idea as to what you might be
thinking  |
|
| |
|
| Back to top |
Grant Edwards
Guest
|
| Posted: Wed Oct 29, 2008 9:34 pm Post subject: Re: Multiple programs accessing serial device |
|
|
On 2008-10-29, Nate Eldredge <nate@vulcan.lan> wrote:
| Quote: | You're welcome. I recently had a conversation with a
programmer with a Windows background who was working on a
project on Unix, which had several instances of his program
using the same file. He was amazed to learn that Unix would
allow more than one process to write to a file at the same
time. (I on the other hand remember being amazed when I found
that Windows would not.)
|
I remember being stunned when I found out that on windows you
can't even read a file to which somebody else is writing. I
had written a program that was writing messages to a log file,
and I just couldn't believe that I wasn't allowed to read the
messages until after the program closed the file. [I still
have no idea why there should be such a limitation.]
--
Grant Edwards grante Yow! I'm a fuschia bowling
at ball somewhere in Brittany
visi.com |
|
| |
|
| Back to top |
Christoph Kobe
Guest
|
| Posted: Fri Oct 31, 2008 6:34 pm Post subject: Re: Multiple programs accessing serial device |
|
|
On Wed, 29 Oct 2008 11:34:24 -0500
Grant Edwards <grante@visi.com> wrote:
| Quote: | On 2008-10-29, Nate Eldredge <nate@vulcan.lan> wrote:
You're welcome. I recently had a conversation with a
programmer with a Windows background who was working on a
project on Unix, which had several instances of his program
using the same file. He was amazed to learn that Unix would
allow more than one process to write to a file at the same
time. (I on the other hand remember being amazed when I found
that Windows would not.)
I remember being stunned when I found out that on windows you
can't even read a file to which somebody else is writing. I
had written a program that was writing messages to a log file,
and I just couldn't believe that I wasn't allowed to read the
messages until after the program closed the file. [I still
have no idea why there should be such a limitation.]
|
I remember beeing stunned when I first learned about all the
advantages (and some disadvantages) of my linux system. I remember
installing a rather early version of it (kernel 2.0.???), no GUI,
sitting in front of the console and having no idea what to do with
it
But now I'm happy with it running 24/7, doing lots of things that
are amazing and I did not pay a single euro for the software.
On 2008-10-29, Christoph Kobe <christoph@kobenetz.de> wrote:
| Quote: | But on the other hand I'm coming from the windows-world where I see
little cooperation bewtween programs and where in some cases it's
necessary to exclude other programs run by the same user from acessing
the same device.
|
You should be able to do that under Unix by using the TIOCEXCL
ioctl.
Ok, I learnt that I don't need it anymore, but maybe I'll try it anyway  |
|
| |
|
| Back to top |
|
