Whoops... I'm getting the messages from 3 systems, all running
6.4-STABLE, with no local modifications, under both VMware and
Openstack, using openup to keep systems updated. Dmesg available if
anyone thinks it's relevant.
-Adam
On 2019-02-25 08:50, Adam Thompson wrote:
Hi,
I'm getting daily insecurity (i.e. security(8)) nags about userids
that are off but still have a valid shell and access files.
(Specifically, I'm getting the nag from check_access_files() in
/usr/libexec/security.)
Since ports (at least in my experience) regularly creates userids that
will trigger this warning, what's the "best" way to disable the
warning? I'm reluctant to mess with permissions on directories
created by packages, but maybe that's the best way?
Otherwise, it looks like I can disable the warning by setting a
password on the userid in question.
However, that leads to the question: what if I don't *want* a password
on the account, because it's supposed to be a SFTP-only,
public-key-authentication-only account, but still needs to be readable
and needs a valid shell for various cron jobs to be happy? If I'm
following the logic correctly, one of the warnings I'm getting is for
~/.ssh being readable on a userid with no password - exactly the
scenario I just mentioned. But AFAIK they can't login if I take away
S_IRUSR on ~/.ssh?
The most distasteful option is to hack /usr/libexec/security to ignore
certain userids, but ... it's there for a reason.
The cleanest example I have right now from ports is _rancid, created
by the rancid package, and triggered by the existence of ~_rancid/.ssh
with S_IRUSR (u+r) permissions.
Suggestions / advice?
Thanks,
-Adam
