Re: security - preferred way to make check_access_file happy?

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