Running the following command gave an unexpected result: # passwd -S -a ... portage P 06/25/2012 0 99999 7 -1 ... The portage account seems not to be locked by default: the second field above should be an "L", not a "P". I checked this on four systems of different ages and got the same result. To the best of my knowledge no changes were made to these systems that would cause this, so I am assuming it is a default state. The cause here seems to be that there is no "!" for the account's password field in /etc/shadow. Instead there is an "x"; this does prevent any password-based login (and of course the shell is /bin/false). But according to shadow(5) this leaves the account technically unlocked, and so potentially accessible through other authentication means, for systems that use them (admittedly I can not think of a good example). Also, for auditing purposes this is a red flag.
It can be useful to sporadically log in to portage account and perform some operations e.g. in ${DISTDIR}. Some tools will not work when run by inappropriate user. When I am logged in as root and cd to e.g. ${DISTDIR}/hg-src/python/cpython, then e.g. `hg pull` command fails with 'not trusting file ${DISTDIR}/hg-src/python/cpython/.hg/hgrc from untrusted user portage, group portage\nabort: repository default not found!' message. After logging in as portage, that command works.
Old. No actual concern here as the account is restricted from being logged in to and no example of an actual exploit has been given.
