3 ms·
But we have a great, robust way to see exactly who modified a file and when; it's the file system. Why reinvent it? That's a strange statement given your backg
by moe 14y ago
But we have a great, robust way to see exactly who modified a file and when; it's the file system. Why reinvent it?
That's a strange statement given your background.
Since when does editing a file change the owner or leave an audit-trail behind, on stock linux?
If you're running auditd then that's a different story but I've never seen that used in production for this purpose because it's hard to get right and because there are so many
simpler options much better suited to the task (version control, puppet, chef, etc.).
Auditing or not, in my experience you inevitably end up in permission-hell when multiple users mess with files that need to be readable by a common gid (sticky bits, umask, something is always off).
If you really found a way to make this work at scale, a detailed write-up would be interesting (to me).
In my experience that way lies unmitigated madness. I've had to clean up multiple such "sudo-style" deployments in the past.
- jaylevitt 14y agoGAH! See, I just slipped up and showed my age. I'm thinking of the Stratus VOS filesystem, which did change the modifier when you edited a file. You're right; UNIX/Linux files have an owner, which doesn't change on modification. Which shoots a big blazing hole in my argument. You can back into who modified what if files were changed in a big batch, and they also created a few new files - but you could also back into that via login times. Since those days, it's less that I've seen the individual-user system work at scale - it's that I've seen the single role account fail, repeatedly. I've managed to avoid permissions hell with a few well-chosen supplemental groups, but maybe I'm too optimistic that what used to work in one environment will work in another. Ask me in six months. :)