Inter-process Semaphores and /dev/shm
Carlos Moreno
I'm somewhat puzzled by the following:
I'm doing a quick sample program for named semaphores; on my local,
Ubuntu machine, the program works perfectly; I upload it to another
machine, running Fedora Core 6, and the call to sem_open fails with
errno = 13 (EACCESS). The call looks like:
sem_t * sem = sem_open ("test_sem", O_CREAT, 0600, 0);
if (sem == NULL)
{
cerr << "Sem_open failed --- errno: " << errno << endl;
return 1;
}
It seems to boil down to the permissions for /dev/shm --- on my
Ubuntu
machine, /dev/shm is owned by root, with permissions drwxrwxrwt,
whereas on the Fedora machine, it has persmissions drwxr-xr-x (also
owned by root, of course).
Is it simply a matter of setting the permissions to allow non-root
users
to create named semaphores (and set the sticky bit) ? Would I be
opening a can of worms by doing that?
If that's what I should do, I wonder: what could possibly be the
point
of a default configuration where non-root users can not create
semaphores?
Seems quite absurd to me --- am I missing something? (it does feel
like
I am missing something)
Thanks for any comments,
Carlos
--
Mikko Rauhala
<cm_...@mailinator.com> wrote:
> I'm doing a quick sample program for named semaphores; on my local,
> Ubuntu machine, the program works perfectly; I upload it to another
> machine, running Fedora Core 6, and the call to sem_open fails with
> errno = 13 (EACCESS). The call looks like:
I'm guessing FC6 didn't have a tmpfs mounted at /dev/shm per default
yet, as nowadays should be. (You can use something else there, of course,
but a tmpfs is generally the sane choice.)
--
Mikko Rauhala - m...@iki.fi - <URL: http://www.iki.fi/mjr/ >
Transhumanist - WTA member - <URL: http://transhumanism.org/ >
Singularitarian - SIAI supporter - <URL: http://singinst.org/ >
Carlos Moreno
Hi Mikko, thanks for your message!
> I'm guessing FC6 didn't have a tmpfs mounted at /dev/shm per default
> yet, as nowadays should be. (You can use something else there, of course,
> but a tmpfs is generally the sane choice.)
Indeed.
Not sure what you meant by "use something else there" --- I tried
just changing the permissions (chmod 777 /dev/shm; chmod +t /dev/
shm)
and now the sample program with the semaphores did work (and I do
see the files under /dev/shm).
After doing a quick search, I understand a little better what you are
referring to, and I guess the effect of the chmod is that shm entries
would be permanent? (plus possibly subject to other negative side-
effects?)
I just added the following line to /etc/fstab, which seems to fix
things
(and it seems to be what Ubuntu and CentOS 5.1 do):
tmpfs /dev/shm tmpfs defaults 0 0
Now the directory does show with permissions rwxrwxrwt, and things
work --- I imagine this is what you are referring to when you talk
about the "sane choice"?
Thanks!
Carlos
--
Mikko Rauhala
<cm_...@mailinator.com> wrote:
> Not sure what you meant by "use something else there" --- I tried
> just changing the permissions (chmod 777 /dev/shm; chmod +t /dev/
> shm)
> and now the sample program with the semaphores did work (and I do
> see the files under /dev/shm).
Yeah that probably works, and /dev is a tmpfs anyway on udev systems
(~all modern GNU/Linux distros). Still, having a separate tmpfs on the
shm node is advisable as it'll make shm and the rest of /dev have their
own size limits...
> After doing a quick search, I understand a little better what you are
> referring to, and I guess the effect of the chmod is that shm entries
> would be permanent? (plus possibly subject to other negative side-
> effects?)
It would be so if /dev resided on a physical filesystem.
> tmpfs /dev/shm tmpfs defaults 0 0
>
> Now the directory does show with permissions rwxrwxrwt, and things
> work --- I imagine this is what you are referring to when you talk
> about the "sane choice"?
Yeah, that's pretty much how it should be.