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
