From nobody Sun Jun 09 16:09:37 2024 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vy0JG5rxVz5MP7h for ; Sun, 09 Jun 2024 16:09:50 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4Vy0JG04xXz4S81 for ; Sun, 9 Jun 2024 16:09:50 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=ilk.org; spf=pass (mx1.freebsd.org: domain of freebsd-questions-local@be-well.ilk.org designates 23.30.133.173 as permitted sender) smtp.mailfrom=freebsd-questions-local@be-well.ilk.org Received: from lowell-Ubuntu.lan (lowell-Ubuntu.lan [172.30.250.95]) by be-well.ilk.org (Postfix) with ESMTP id 8877220444; Sun, 09 Jun 2024 12:09:37 -0400 (EDT) Received: by lowell-Ubuntu.lan (Postfix, from userid 1147) id 51C28108042F; Sun, 9 Jun 2024 12:09:37 -0400 (EDT) From: Lowell Gilbert To: D'Arcy Cain Cc: questions@freebsd.org Subject: Re: Confusing security report 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> <16a0e80a-27d0-448a-9bc0-d123d95b4a96@druid.net> Reply-To: questions@freebsd.org Date: Sun, 09 Jun 2024 12:09:37 -0400 Message-ID: <44le3e3xoe.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.35 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.65)[-0.647]; DMARC_POLICY_ALLOW(-0.50)[ilk.org,none]; R_SPF_ALLOW(-0.20)[+a]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:7922, ipnet:23.30.0.0/15, country:US]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[questions@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_REPLYTO(0.00)[questions@freebsd.org] X-Rspamd-Queue-Id: 4Vy0JG04xXz4S81 D'Arcy Cain 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.