On Tue, Feb 23, 2021 at 3:15 PM Branko Čibej <br...@apache.org> wrote: > > On 23.02.2021 17:46, Daniel Shahaf wrote: > > If a cron job needs authentication, its credentials need to be stored > > somewhere, either in plaintext or in "as good as" plaintext. I think > > storing the passwords in unobfuscated plaintext was a deliberate > > decision, informed by CVS's design choices in this regard, but I wasn't > > around in the early days. > > It was deliberate. Reading those passwords requires access to the > filesystem, so an attacker either has the affected user's credentials -- > in which case they probably have access to any encrypted password store > as well -- or they're root, and in _that_ case all bets are off anyway.
Sadly, with docker, VM's, filesystem snapshots ,and home directories on NFS shares exported to the world at large without Kerberos authenticaiton (which I saw a bunch of computer science professors at MIT insist on, until finally MIT's IT group stepped on them for it and shoved them behind NAT), it's too easy to steal such credentials. > Note that recently operating systems have gone in the direction of _not_ > letting root do everything without extra checks, so maybe the second > assumption needs to be reconsidered. > > In any case, encrypted or otherwise protected password stores have > master passwords that have to be stored somewhere for unattended > operation, so that's just moving the problem one level of indirection away. No. They don'.t. A session can be unlocked with which the live user or service user can make a successful connection. The private key lives in RAM, not on disk, and the key needs to be unlocked at user login or at system start. This was what the old "keychain" perl script provided along with ssh-agent.
