[squid-dev] To make squid works in snap world.

Alex Rousskov rousskov at measurement-factory.com
Wed Mar 15 16:33:43 UTC 2017


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.



More information about the squid-dev mailing list