Restrict access to the home directory by default #205
Conversation
maxpoulin64
added
Type: Feature
| @@ -23,7 +23,7 @@ if (program.home) { | |||
|
|
|||
| var config = Helper.HOME + "/config.js"; | |||
| if (!fs.existsSync(config)) { | |||
| mkdirp.sync(Helper.HOME); | |||
| mkdirp.sync(Helper.HOME, {mode: 0o0700}); | |||
There was a problem hiding this comment.
Could you use '0700' instead please?
ESLint is not too happy with this and octal mode is not allowed in strict mode (not that we enforce it at the moment, but it would be nice as it's a simple addition and helps finding out issues...).
|
@JocelynDelalande, would be great if you could take this one! |
Follow up on thelounge#165 Closes thelounge#194
|
(@maxpoulin64, I'll take ownership because @JocelynDelalande is unavailable at the moment. @JocelynDelalande, feel free to take it back if you happen to be back before it gets merged.) Just wondering about the following:
It might be that I am ignorant, and/or that this just applies when the folder gets created the first time, but since you specify "without being instrusive for sysadmins, I just want to make sure we're on the same page :-) |
|
First, sorry for not having time to discuss that quickly. That's life :)
IMHO, it's more intrusive than #165 : by default it shadows all files from every user, even for non-secret settings (I'm thinking specially about config.js). In that, this proposal is quite exotic (look at /etc/fstab, nginx config files, or… any software having shared/config files). I don't say doing as others is always the best, but there is a reason : leaving by default access to non-sensitive information to other unix user allows them to know what are the settings of the software they may be using . It also prevents getting the admin/sudo rights when not strictly necessary (eg: reading the config files). Moreover, . So for now it's a 👎 for me. It doesn't prevent from hardening if an adminsys wants to. I'm just suggesting that our default rights policy matches with other software default practices, for a consistent adminsys/user experience. So I still think #165 amended with @maxpoulin64 suggestion, is less intrusive and more "right" than this one. I resume discussion on #165. |
|
@JocelynDelalande What if stricter mode was set on the users folder? https://github.com/maxpoulin64/lounge/blob/I-194/src/command-line/add.js#L14 I'm of opinion that we don't really need to be messing with modes at all, but if we are going to, doing it on users folder should be a good compromise. |
I don't think it is as it's only set when the folder gets created. But when it gets applied, indeed everything goes in the dark.
Software you mention usually leave modes alone and therefore rely on the So in short I agree with @xPaw here: let's leave modes alone for the configuration file, and harden them on the All that being said, my concerns above still apply, mainly: why setting |
|
@astorije 700 is not a bad default for users folder. I was looking at znc, and they default creating folders to that too. |
|
@xPaw, fair enough, and admins can set specific group permissions directly if needed (but then |
|
I'll 👍 this. We store passwords in the configuration files, and the config folder is inside of the user folder. On top of that, this change only affects creation of the folder. If a user wishes to set wider permissions on the folder, they absolutely can. |
|
So, can we finally merge this? |
|
Bump? |
|
Yes. After all, this is very innocent, and we haven't heard from @JocelynDelalande in more than a month. |
Sensitive information is protected by thelounge/thelounge#205 for Docker builds, but deb installs did not benefit due to the pre-existence of the home directory, created at build time.
Sensitive information is protected by thelounge/thelounge#205 for Docker builds, but deb installs did not benefit due to the pre-existence of the home directory, created at build time.
Sensitive information is protected by thelounge/thelounge#205 for Docker builds, but deb installs didn't benefit, due to the home dir already existing, created at build time.
Sensitive information is protected by thelounge/thelounge#205 for Docker builds, but deb installs didn't benefit, due to the home dir already existing - created at build time.
Sensitive information is protected by thelounge/thelounge#205 for Docker builds, but deb installs didn't benefit, due to the home dir already existing - created at build time.
As discussed in #165, this PR restricts the permissions on the entire home directory, making it secure by default without being instrusive for sysadmins.