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 >
slightly dirty (but reliable) hack: set the password to thirteen *'s instead of just one, so it looks like a DES crypted password instead, like all the users present in the base OS or added by normal pkg_add. of course this makes the /etc/security check not entirely useful, because one could quietly create .ssh/authorized_keys for a home dir for a "ports" uid and security won't pick it up ...
