Hi Steve, You're talking about https://github.com/apache/guacamole-server/blob/master/src/libguac/pool.c , I presume? In that case you're right unless - the malloc and pthread_* functions are redefined to mean something weird, or - the physical page containing malloc'ed pool is later made shared between processes, or is flagged to be shared with a child after forking, or remapped to another virtual address in the same process, all of which are highly unlikely.
So a process-shared mutex is unnecessary here on any POSIX system, not only on OpenBSD. Nick Permyakov > Hi, > > I am looking into guacamole's use of pthread_mutexattr_setpshare. > (an aside, if I comment out the 4 lines of code invoking > pthread_mutexattr_setpshare, it compiles with gcc on OpenBSD 6.6 > (GENERIC.MP) ) > > I am an experienced C programmer, but I've never looked in threading in > C before so it has required quite a bit of reading. I haven't been able > to find a comprehensive "architecture" document, just various man pages, > some with sample code. > > For example: > https://linux.die.net/man/3/pthread_mutexattr_init > > In the above documentation, it states: > > ...the possibility that an application may allocate the > synchronization objects from this section in memory that is accessed > by multiple processes (and therefore, by threads of multiple processes). > > That is the purpose of the guacamole's pthread_mutexattr_setpshared(foo, > PTHREAD_PROCESS_SHARED) , to permit multiple threaded processes to > access the resource protected by the MUTEX. > > However, from my reading of the code, the MUTEX is only protecting > malloc'd memory, which as far as I know, isn't a resource that can be > accessed by multiple processes. > > It is my newby (to pthreads) interpretation of the code that in all 4 > cases, the code is malloc'ing memory that is being protected by the > MUTEX. For example: > > src/libguac/pool.c: > ... > guac_pool* guac_pool_alloc(int size) { > > pthread_mutexattr_t lock_attributes; > guac_pool* pool = malloc(sizeof(guac_pool)); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Allocate memory that will only be accessible by this process > > /* If unable to allocate, just return NULL. */ > if (pool == NULL) > return NULL; > > /* Initialize empty pool */ > pool->min_size = size; > pool->active = 0; > pool->__next_value = 0; > pool->__head = NULL; > pool->__tail = NULL; > > /* Init lock */ > pthread_mutexattr_init(&lock_attributes); > pthread_mutexattr_setpshared(&lock_attributes, PTHREAD_PROCESS_SHARED); > pthread_mutex_init(&(pool->__lock), &lock_attributes); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This codes saves the MUTEX in the locally allocated memory > > No other process can find this MUTEX in malloc'd memory, so setting it > to PTHREAD_PROCESS_SHARED seems totally irrelevant. > > If so, I *think* it's OK to just comment out that code as OpenBSD's > pthread implementation will work fine within a process, just not > multiple processes. > > Is this a correct assessment of the code and OpenBSD's pthread environnment? > > Thanks, > Steve W. > > On 15/04/2020 10:19 a.m., Stuart Henderson wrote: > > On 2020-04-14, Steve Williams <st...@williamsitconsulting.com> wrote: > >> Guacamole (I believe) needs to run under something like tomcat to serve > >> up the java war file & application. > > I looked at this before - it also requires guacamole-server to be built > > (written in C), it requires mutexes shared between different processes > > (pthread_mutexattr_setpshared(foo, PTHREAD_PROCESS_SHARED) which > > isn't supported in OpenBSD's thread library. > > > > But what you can do is run guacamole elsewhere and have a reverse http > > proxy running on OpenBSD doing http auth and feeding connections across. > > > >> So, I was thinking of using some form of authpf to open up pf rules when > >> I needed to access systems remotely. > >> > >> But, I don't want to open up Tomcat to the world when I'm using > >> guacamole, so is it possible to have authpf tweak pf rules so that the > >> originating IP address of the ssh session would be the only one that > >> could access Tomcat? > > That is exactly what authpf normally does anyway. > > > >> I was thinking even httpd in front of tomcat with httpd authentication, > >> but that doesn't seem to make sense to me at a high level. > >> > >> I was looking at relayd but it doesn't seen to have any authentication > >> mechanism built in. > > httpd can't proxy connections to another http server. relayd can but as > > you say doesn't have a way to add http authentication. You can do this > > with nginx, haproxy or Apache httpd though. > >
