Re: [Boost-users] shmem on multi-user machine

From: Steven Wooding (steve.apo_at_[hidden])
Date: 2006-08-01 17:07:19

Hi Berenguer,

Here are the exchanges myself and Ion have been having. Sorry this was not
copied to the Boost list.

Steve.

==========================================================
Ion Gaztañaga to me
 More options  26-Jul (6 days ago)
Hi Steven,
- Show quoted text -

> I've noticed that the "file" /dev/shmem/sem.boost_shmem_shm_global_mutex
> keeps hanging around after my program finishes. This file has write
> permission only for the user that created it. When different user comes
> along a runs another program that uses shmem, it seg faults on
> sem_wait(), probably due to the file permissions.
>
> Should this global mutex be cleaned up after use? Or could the
> permissions be changed somehow to let other use it (though probably not
> a good idea if user A and user B run a shmem based program at the same
> time).

Umm. I haven't thought about this, but it's sure that using the lock
leads to some problems. I really don't know how to solve this, because
I'm not a UNIX user, do you have a suggestion? The global mutex is used
to implement mutual exclusion when initializing the shared memory from
different processes, so it's created with all permissions (well, I
suppose those are masked by the security mask). However, I see a huge
security problem, so I don't know how should I proceed. Any suggestion
is welcome.

Regards,

Ion

==============================================================

Steven Wooding to Ion
 More options  14:31 (7 hours ago)
Hi Ion,

I've come up with a solution that works us OK. What I've done is add the
username of the user executing the program that uses shared memory to the
end of the global mutex name (using getenv("LOGNAME")). So each user now has
their own shmem global mutex to play with.

I've also found that it was too easy to create a shared memory region larger
than what was available on the /dev/shm filesystem. My solution to this is
to add a check of the filesystem that m_shmHnd is on (should be /dev/shm)
using the fstatfs system call.

Below are my changes against the 0.93 version of shmem. Please feel free to
include, modify or discard these suggestions as you see fit. If they are in
the official release of shmem, then that means we don't have to maintain
patches in the future.

I hope I have been of some help.

Cheers,

Steve.

===================================================================

RCS file: boost/shmem/shared_memory.hpp,v

retrieving revision 1.2

retrieving revision 1.4

diff -u -r1.2 -r1.4

--- shared_memory.hpp 2006/07/03 14:14:46 1.2

+++ shared_memory.hpp 2006/08/01 13:06:22 1.4

@@ -31,6 +31,7 @@

# include <semaphore.h> //sem_t* family, SEM_VALUE_MAX

# include <string> //std::string

# include <sys/stat.h> //mode_t, S_IRWXG, S_IRWXO, S_IRWXU,

+# include <sys/vfs.h> // fstatfs

# else

# error Unknown platform

# endif

@@ -534,8 +535,11 @@

inline bool shared_memory::GlobalNamedScopedMutex::acquire()

{

+ char globalMutexName[64];

+ strcpy(globalMutexName, "/boost_shmem_shm_global_mutex-");

+ strcat(globalMutexName, getenv("LOGNAME"));

mode_t mode = S_IRWXG | S_IRWXO | S_IRWXU;

- m_sem = sem_open("/boost_shmem_shm_global_mutex", O_CREAT, mode, 1);

+ m_sem = sem_open(globalMutexName, O_CREAT, mode, 1);

if(m_sem == ((sem_t*)-1))

return false;

m_acquired = sem_wait(m_sem) == 0;

@@ -616,6 +620,21 @@

}

else{

created = true;

+ // Check to see if there is enough space on the shared memory file system
to create the

+ // new shared memory segment area

+ struct statfs statfsResult;

+ if ( fstatfs( m_shmHnd, &statfsResult) == -1)

+ {

+ this->priv_close_handles();

+ shm_unlink(name);

+ return false;

+ }

+ if ( size > ( statfsResult.f_bavail * statfsResult.f_bsize))

+ {

+ this->priv_close_handles();

+ shm_unlink(name);

+ return false;

+ }

// Set the memory object's size

if( ftruncate( m_shmHnd, size ) == -1 ) {

this->priv_close_handles();

========================================================

Ion Gaztañaga to me
 More options  19:49 (2 hours ago)
Hi Steven,
> Hi Ion,
>
> I've come up with a solution that works us OK. What I've done is add the
> username of the user executing the program that uses shared memory to
> the end of the global mutex name (using getenv("LOGNAME")). So each user
> now has their own shmem global mutex to play with.

This does not solve the problem where two different users can share the
same segment, but at least, does not block new users.

> I've also found that it was too easy to create a shared memory region
> larger than what was available on the /dev/shm filesystem. My solution
> to this is to add a check of the filesystem that m_shmHnd is on (should
> be /dev/shm) using the fstatfs system call.

I didn't know it was possible to create a shared memory region bigger
than the available. Shouldn't ftruncate fail if we try to do this?

Thanks for the patch. I will add it ASAP.

Regards,

Ion.

=================================================================
Steven Wooding to Ion
 More options  19:54 (2 hours ago)
Hi Ion,

>
> This does not solve the problem where two different users can share the
> same segment, but at least, does not block new users.

In my application, the user can adjust the name of the shared memory segment
as a run-time variable, so I just told them to add their user name to the
end of the name to avoid this.

I didn't know it was possible to create a shared memory region bigger
> than the available. Shouldn't ftruncate fail if we try to do this?

No, it doesn't. The only time you know about it is when you actually use the
shared memory segment past what's available. Then you get bus errors and the
system crashes. Very bad.

Some people on the Boost list seem to what to know the answer to my original
question. The discuss between me and you has been private up til now. Shall
I post our exchange?

Cheers,

Steve.

==================================================================
Ion Gaztañaga to me
 More options  20:10(1 hour ago)
> No, it doesn't. The only time you know about it is when you actually use
> the shared memory segment past what's available. Then you get bus errors
> and the system crashes. Very bad.

Umm. That sounds really bad. However, this seems too linux specific,
since posix shared memory mounting point can be anywhere. I would need
to investigate this issue further to know if mmap can be told to reserve
all the memory, instead of waiting bus errors.

Regards,

=====================================================
Steven Wooding to Ion
 More options  21:59 (0 minutes ago)

>
> Umm. That sounds really bad. However, this seems too linux specific,
> since posix shared memory mounting point can be anywhere. I would need
> to investigate this issue further to know if mmap can be told to reserve
> all the memory, instead of waiting bus errors.
>
>
Doesn't my use of fstatfs that takes the file descriptor as the input
argument avoid knowing where the mount point is?

Cheers,

Steve.