Squid logs are re-owned by root:wheel



  • On each pfSense startup, as well as regularly after (but only if anyone was using the proxy), the owner of /var/log/squid directory reverts to root:wheel — no matter how many times do I change it back to proxy:proxy. The contents of log files is left intact, but Squid can't write to them, so it refuses to function at all.

     12:58:21 squid[43282]: Squid Parent: child process 43914 started
     12:58:22 php: : Not calling package sync code for dependency squid of squid because some include files are missing.
     12:58:28 squid[43282]: Squid Parent: child process 43914 exited with status 0
    
     12:58:54 squid[60919]: Squid Parent: child process 61368 started
     12:58:54 squid[61368]: Cannot open '/var/log/squid/access.log' for writing. The parent directory must be writeable by the user 'proxy', which is the cache_effective_user set in squid.conf.
     12:58:54 squid[60919]: Squid Parent: child process 61368 exited due to signal 6
     12:58:54 kernel: pid 61368 (squid), uid 62: exited on signal 6
    
     12:58:57 squid[60919]: Squid Parent: child process 62380 started
     12:58:58 squid[62380]: Cannot open '/var/log/squid/access.log' for writing. The parent directory must be writeable by the user 'proxy', which is the cache_effective_user set in squid.conf.
     12:58:58 squid[60919]: Squid Parent: child process 62380 exited due to signal 6
     12:58:58 kernel: pid 62380 (squid), uid 62: exited on signal 6
    
     12:59:01 squid[60919]: Squid Parent: child process 21548 started
     12:59:01 squid[21548]: Cannot open '/var/log/squid/access.log' for writing. The parent directory must be writeable by the user 'proxy', which is the cache_effective_user set in squid.conf.
     12:59:01 squid[60919]: Squid Parent: child process 21548 exited due to signal 6
     12:59:01 kernel: pid 21548 (squid), uid 62: exited on signal 6
    
     12:59:04 squid[60919]: Squid Parent: child process 22197 started
     12:59:04 squid[22197]: Cannot open '/var/log/squid/access.log' for writing. The parent directory must be writeable by the user 'proxy', which is the cache_effective_user set in squid.conf.
     12:59:04 squid[60919]: Squid Parent: child process 22197 exited due to signal 6
     12:59:04 kernel: pid 22197 (squid), uid 62: exited on signal 6
    
     12:59:07 squid[60919]: Squid Parent: child process 41510 started
     12:59:07 squid[41510]: Cannot open '/var/log/squid/access.log' for writing. The parent directory must be writeable by the user 'proxy', which is the cache_effective_user set in squid.conf.
     12:59:07 squid[60919]: Squid Parent: child process 41510 exited due to signal 6
     12:59:07 kernel: pid 41510 (squid), uid 62: exited on signal 6
     12:59:07 squid[60919]: Exiting due to repeated, frequent failures
    
     {after manually "chown -R proxy:proxy /var/log/squid"}
     12:59:54 squid[605]: Squid Parent: child process 941 started
    

    I checked scripts in /usr/local/etc/rc.d — none of them does this. Then tried to use shellcmd, as well as earlyshellcmd, but nothing helped.

    pfSense is v2.0.1, Squid is v2.7.9 (pkg v4.3.1).

    PS. Another strange change upon each reboot is the disappearance of /var/run/named directory. My first thought was that the entire /var directory is not preserved between restarts, but it was obviously not the case as other files weren't touched.


  • Rebel Alliance Developer Netgate

    Are you on NanoBSD or a full install?

    On NanoBSD, /var is a RAM disk and it is indeed wiped out on reboot since it doesn't live anywhere permanent.



  • @jimp:

    Are you on NanoBSD or a full install? On NanoBSD, /var is a RAM disk.

    Of course, the topic in question is the full harddisk installation; otherwise it wouldn't be surprising — just like commodity SOHO routers do.

    As I said, Squid logs are preserved on reboot — but their ownership is not: on each reboot (more precisely, some time after shellcmd directives are executed), the whole /var/log directory is re-owned by root:wheel. And even then, with proper proxy:proxy ownership applied by hand and Squid restarted, after using the proxy for some hours, the owner is again switched to root:wheel.

    I would think that it's an intented behaviour of pfSense to keep all log files owned by superuser, and that Squid simply doesn't comply with this policy, — unless Squid was not a specially-crafted pfSense-aware package used by many people for years.



  • Your original post mentions /var/log/squid but on my systems it is /var/squid/logs
    /var/squid is owned by proxy:proxy
    everything else in /var (including /var/log) is owned by root:wheel
    I am surprised that your squid logs are living inside /var/log



  • @phil.davis:

    You mention /var/log/squid, but on my systems it is /var/squid/logs. I am surprised that your Squid logs are living inside /var/log.

    Why does non-factory path seem so unusual to you?

    • Squid's webConfigurator in pfSense not only provides standard mean of changing log location on the very first page, but also marks this field as “required” (rather than non-required, “default”, which could have a default value if you don't fill in anything).
    • It's natural to store logs in /var/log, especially if you have a dedicated partition for this. (At the time of installing pfSense, I didn't yet know that there is little point for this, since native pfSense logs are circular, and it can't be switched off.)
    • There is no problem with storing Squid's logs outside of /var/squid directory, as Squid in pfSense isn't run in chroot jail (in contrast with BIND, for example).

    If you Google for “/var/log/squid”, you'll find that this path is quiet common (in other systems).

    @phil.davis:

    /var/squid is owned by proxy:proxy
    everything else in /var (including /var/log) is owned by root:wheel

    That's what I'm trying to figure out:

    • Is keeping /var/log owned by superuser an absolute requirement for pfSense to function? (Why?) Can it be disabled somehow?
    • If it's system feature, why doesn't Squid package compensate for this (protecting its logs), or at least warn about inevitable problems?
    • May it be an interference with some other package? (I also have FreeRadius2 and NUT installed, along with BIND binary package.)

    I'm currently out of ideas how to determine the cause of such a strange, seemingly unnecessary behaviour.



  • Squid sets cache_effective_user to "proxy" in its conf file. So wherever the log location for Squid is put, it needs to be writeable by "proxy", as you know. But var/log also gets lots of other log files in it from other processes. I suspect that pfSense wants /var/log to be owned by root and not visible to less-priv users for security - stopping less-priv processes from seeing other processes log files?
    I'll let someone in-the-know comment on the intended design…



  • Did you tried to link your large filesystem to /var/squid and use "default" path?



  • @marcelloc:

    Did you tried to link your large filesystem to /var/squid and use "default" path?

    Already thought of moving /var/log back to “/var” partition and then using that old “/var/log” partition for non-system (non-circular) logs only, under a different mount-point, but still have no idea how to accomplish this on a running system. Perhaps, a live CD environment could help with this.

    Just curious about what makes such unexpected changes to file system, provided that everything would work just fine without them.


  • Rebel Alliance Developer Netgate

    In /etc/rc, /var/log/ is wiped out, and the files are freshly made.

    One of many reasons the squid package keeps its logs separate.

    That behavior has changed (as of e8197e56f360f222d03de24f8b66fe5125123c30 on master) for the full install, but still wouldn't be recommended.


Log in to reply