On 03/15/2017 03:24 AM, Gary Wang wrote: > Regarding the confinement of usage of shared memory in snap world, > Please take a look at the bug > https://bugs.launchpad.net/snappy/+bug/1653955
The above bug is about semaphores. Squid does not use semaphores (our implementation of shared memory objects is lockless). Squid uses shared memory segments created by shm_open(), not sem_open() system calls. The above bug description appears to imply that snap allows /dev/shm/snap.@{SNAP_NAME}.* names, which are not the names used in your prior examples (IIRC). The sem.* pattern you used confused reviewers into thinking that you are trying to solve the wrong problem. The actual problem you are trying to solve (AFAICT) is valid and is not about the "sem." prefix but about the "snap." prefix. > And Jamie's reply can be fuond in snapcraft maillist > https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg02465.html Again, that feels like an irrelevant piece of information here because it is specific to semaphores that Squid does not use. If I am right, then your argument should be something like this: 1. Snap does not allow arbitrary names in /dev/shm/. 2. Snap allows names matching /dev/shm/snap.@{SNAP_NAME}.* (and others) 3. I need to make Squid names for /dev/shm/ files configurable so that they can be forced to match one of the snap-allowed patterns. Please note that it is theoretically possible that OS shm_open() implementation (in Squid context) creates some secret temporary files just like sem_open() does in Python context. That would mean that other names/patterns may be in play here as well. However, since you know that your patch "works", my argument sketch above remains valid even if there are other OS-created names that we do not know about. HTH, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev