Date: Sun, 09 Jun 2024 12:09:37 -0400 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: D'Arcy Cain <darcy@druid.net> Cc: questions@freebsd.org Subject: Re: Confusing security report Message-ID: <44le3e3xoe.fsf@be-well.ilk.org> In-Reply-To: <16a0e80a-27d0-448a-9bc0-d123d95b4a96@druid.net> (D'Arcy Cain's message of "Sat, 8 Jun 2024 11:13:53 -0400") References: <9381aabf-f95c-4d0e-912a-4aeb36c767bd@druid.net> <si7g6yqkfaylfpd4pbaccxdabx2etlpafjdmxqepvohnceujjl@p4h6tatk25jz> <16a0e80a-27d0-448a-9bc0-d123d95b4a96@druid.net>
next in thread | previous in thread | raw e-mail | index | archive | help
D'Arcy Cain <darcy@druid.net> writes: > I thought I explained that but let me expand. I have a login.conf in > my subversion repository which is checked out on every server in my > farm. At boot time it runs this command: > > cap_mkdb -f /etc/login.conf /Vybe/etc/general/login.conf > > So that creates the /etc/login.conf.db. If that db file exists it > will be used regardless of whether /etc/login.conf exists. > > I thought I could simply symlink the repo file into /etc but I am > pretty sure that would give me the same ownership warning. It will make the same test against the real file. If that gives you a warning, I'd be inclined to tighten up how the repo gets checked out. This does suggest that maybe a similar check should be made on the .db file, though. I'm not sure exactly how that should be implemented; for my own purposes I would automatically regenerate the db, but I'm not sure there's any one action that would be appropriate for everyone. For cases where you know for sure that this check is always a false positive, disabling the check is easy. For more complicated local situations, customizing the logincheck script is only slightly more complicated. In short, there are a lot of reasonable ways to deal with this situation. Season to taste. Be well.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44le3e3xoe.fsf>