Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Squid logs are re-owned by root:wheel

    pfSense Packages
    4
    9
    5091
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      Samsonov last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • jimp
        jimp Rebel Alliance Developer Netgate last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • S
          Samsonov last edited by

          @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.

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis last edited by

            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

            1 Reply Last reply Reply Quote 0
            • S
              Samsonov last edited by

              @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.

              1 Reply Last reply Reply Quote 0
              • P
                phil.davis last edited by

                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…

                1 Reply Last reply Reply Quote 0
                • marcelloc
                  marcelloc last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • S
                    Samsonov last edited by

                    @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.

                    1 Reply Last reply Reply Quote 0
                    • jimp
                      jimp Rebel Alliance Developer Netgate last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post

                      Products

                      • Platform Overview
                      • TNSR
                      • pfSense Plus
                      • Appliances

                      Services

                      • Training
                      • Professional Services

                      Support

                      • Subscription Plans
                      • Contact Support
                      • Product Lifecycle
                      • Documentation

                      News

                      • Media Coverage
                      • Press
                      • Events

                      Resources

                      • Blog
                      • FAQ
                      • Find a Partner
                      • Resource Library
                      • Security Information

                      Company

                      • About Us
                      • Careers
                      • Partners
                      • Contact Us
                      • Legal
                      Our Mission

                      We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                      Subscribe to our Newsletter

                      Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                      © 2021 Rubicon Communications, LLC | Privacy Policy