4

Strangely enough, it appears that Squid cannot start if the squid user is not affected to the UID 100. When trying to use another PID, the service systematically fails to start with the following error:

2016/03/10 10:53:13| storeDirWriteCleanLogs: Starting...
2016/03/10 10:53:13|   Finished.  Wrote 0 entries.
2016/03/10 10:53:13|   Took 0.00 seconds (  0.00 entries/sec).
FATAL: Ipc::Mem::Segment::create failed to shm_open(/squid-cf__metadata.shm): (17) File exists

Squid Cache (Version 3.5.15): Terminated abnormally.
CPU Usage: 0.026 seconds = 0.026 user + 0.000 sys
Maximum Resident Size: 48640 KB
Page faults with physical i/o: 0

Here is how I usually proceed to change a service PID:

  1. vi /etc/group to change service's GID:

    Before:

    squid:*:100:

    After:

    squid:*:1234:

  2. vipw to change the service UID:

    Before:

    squid:*:100:100::0:0:squid caching-proxy pseudo user:/var/squid:/usr/sbin/nologin

    After:

    squid:*:1234:1234::0:0:squid caching-proxy pseudo user:/var/squid:/usr/sbin/nologin

  3. Restore files ownership using the two following commands:

    find / -uid 100 -exec chown -v squid {} +
find / -gid 100 -exec chgrp -v squid {} +

I'm installing Squid in a FreeBSD jail managed with ezjail.

I've thought about IPC's but did not found any IPC using ipcs -a when Squid is running properly.

I've also tried, in a new clean jail, to first create the squid user with a custom UID and then install the squid package to ensure that the right UID is used right from the beginning and no squid user with PID 100 existed at any time, but same issue (I also conclude from this that this issue cannot come from an ownership issue). Setting the UID to 100 make Squid able to boot.

I tried several PID (including lower ones like 101), all of them show the same behavior.

I've also tried to play with the squid_user parameter in rc.conf but with no luck: setting it to either squid or root does not seem to change anything.

I've another jail on the same system with a Squid running with PID 100, but shutting it down did not change the issue in any way (in all cases I would be highly surprised by a interference between two jails).

Mateusz Piotrowski
  • 4,623
  • 5
  • 36
  • 70
WhiteWinterWolf
  • 2,851
  • 2
  • 21
  • 37
  • When you encounter this, `ipcs -m` shows no shared memory segments? The error message suggests that one already exists, _or_ that a file with name like `/squid-cf__metadata.shm` exists somewhere. Does it? – Castaglia Mar 10 '16 at 14:54
  • Does `sysctl -a security.jail.sysvipc_allowed` or `sysctl -a security.jail.allow.sysvipc` show true, or false? I'm wondering whether `ezjail` is configured to allow the jailed process access to SysV IPC resources like shared memory segments. – Castaglia Mar 10 '16 at 15:51
  • What about UIDs _less than_ 100? _I.e._ is there some specially privileged low range of UIDs? If so, that would help direct research into where that privileged range of UIDs is defined. – Castaglia Mar 10 '16 at 16:57
  • @Castaglia: I've deleted my comments to clean a bit, I've finally found the solution, even if I don't like its implications at all :( ... – WhiteWinterWolf Mar 11 '16 at 22:41
  • thanks for following up, and for posting the solution! Indeed the "solution"/consequences are more than a little disturbing. – Castaglia Mar 11 '16 at 22:52

1 Answers1

3

OK, I got it now. After a few check on the FreeBSD forum, I can now confirm that FreeBSD jails act a bit like some Swiss cheese as long as SHM objects are concerned. Indeed, FreeBSD does not provide any isolation at all for SHM objects: all jails can access all SHM objects, system-wide, with no way to prevent it.

The error mentioned in this question is therefore quite logical:

  • When different UID were used, Squid was not able to start because it tried to access SHM objects owned by a different user, hence the error message "create failed to shm_open(/squid-cf__metadata.shm): (17) File exists",
  • When the same UID was used in both installation, Squid started successfully, but the situation was probably even worse since both instances would now fight against the same memory object, rewriting each other data and deleting the object on shutdown...

Because of this, specific measure must be taken to ensure that each Squid instance will use different SHM objects names.

By default, Squid creates the following SHM objects on FreeBSD systems (the exact behavior is OS-dependent):

/squid-cf__metadata.shm
/squid-cf__queues.shm
/squid-cf__readers.shm

squid offers the -n parameter to allow to give a specific name to the instance. Concretely this name will (among other things) replace "squid" in the SHM object names above so the SHM object name will become unique system-wide.

Therefore, when setting-up a new Squid instance in a new jail, it is necessary to edit /etc/rc.conf and add an entry such as below (replace "something_unique" by an instance name unique on your host):

squid_flags="-n something_unique"

This allows to properly start both Squid servers, each one with different UIDs.

Obviously, while a bit out-of-scope here, the fact that Squid's SHM objects can be freely accessed from any jail can constitute a security issue in its own right and must not be ignored...

WhiteWinterWolf
  • 2,851
  • 2
  • 21
  • 37
  • You can use `ipcs` and `ipcrm` to find and remove old shm objects. This is better than create new shm objects without removing previous – Eir Nym Mar 21 '16 at 14:39
  • 1
    @EirNym: Sadly, `ipcs` does not take into account shared memory objects created using `shm_open()`, the only available way to get them is by listing currently opened file descriptors where there are mixed with all other kinds of file descriptors. According to a comment in FreeBSD source code (`sys/kern/uipc_shm.c`), it is not clear yet for the main development team whether `ipcs` should be modified to include this feature, or if another dedicated tool should be developed. Therefore there is currently no clean way to check existing SHM objects on FreeBSD. – WhiteWinterWolf Mar 21 '16 at 15:48