Re: [idea] chmod 0 file secrets
Nick Holland <[email protected]>
| Newsgroups | gmane.os.openbsd.misc |
|---|---|
| Message-ID | <[email protected]> |
On 8/10/26 11:50 AM, broke wrote: > I was thinking whether or not you really need encrypted secrets in a file > when you could possibly just use 'chmod 0' to hide it and view it using > doas. any app with user USER won't be able to access without doas password > and all I need to do is have a good user password. > > Tell me if I am wrong though, just a thought. > Quite wrong... First of all, as far as the OS is concerned, yes, the system administrator (root) has access to everything. But the application managers and data owners may disagree completely on that. For example, as an administrator, I'm responsible for backing up, restoring, and keeping things running on a system. But if that system is a banking application, I should NOT have access to the Personal Identifying Information (account numbers, names, unique identifying numbers, etc.) of the people conducting business with the bank. If that system is an HR employee management system, I should not have access to all employee evaluations, compensation, or future company direction. If the files of that system get backed up to another system, an administrator with root access on the backup system but not the backed- up system now has access to all those "secrets". Your plan also mandates that everything accessing that secret file with a chmod 0 be running as root. That's bad. I probably should have put this closer to the top of the examples, because running things as root is just bad if there is any way to avoid it. When your system is replaced, what do you hope happens with the data on the disk? Pretty trivial for anyone to pop that disk into their own system, become root, and read all YOUR secrets. Now...in some cases, for some purposes, yes, file permissions are sufficient to keep the wrong people out of the data. And they are certainly a good starting point. But they are just one part of the whole file security puzzle. Nick.