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

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

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();

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

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.