Pacemaker sets umask to 026 instead of 022
Bug #1397284 reported by
Andrey Epifanov
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Fuel for OpenStack |
Fix Released
|
High
|
Vladimir Kuklin | ||
4.1.x |
Fix Committed
|
High
|
Sergey Kolekonov | ||
5.0.x |
In Progress
|
High
|
MOS Maintenance | ||
5.1.x |
Fix Committed
|
High
|
Vladimir Kuklin | ||
6.0.x |
Fix Committed
|
High
|
Vladimir Kuklin | ||
6.1.x |
Fix Released
|
High
|
Vladimir Kuklin |
Bug Description
OpenStack services create some files(PIDfiles, namespace, etc) using rootwrap and read them later. It means that these files should have read permission for all, that actually default behavior, but sometimes on CentOS we can see, that files were created without read permission for all (why?!) and OS Services failed to read them.
For now we have a couple of bugs with this root cause:
https:/
https:/
https:/
For the fixing this issue we can setup umask 0022 for the OS Services in OCF scripts or something like this...
tags: | added: low-hanging-fruit |
summary: |
- Default read permission for all on CentOS + Pacemaker umask set to 026 for some strange reason |
Changed in fuel: | |
importance: | Medium → High |
summary: |
- Pacemaker umask set to 026 for some strange reason + Pacemaker umask sets to 026 for some strange reason |
summary: |
- Pacemaker umask sets to 026 for some strange reason + Pacemaker sets umask to 026 instead of 022 |
To post a comment you must log in.
Comment from https:/ /bugs.launchpad .net/neutron/ +bug/1311804:
Ryan Moe (rmoe) wrote on 2014-06-04: #8
This was only a problem on CentOS. The issue was that Pacemaker sets the umask to 026 (this is hard-coded) which gets inherited by all processes that get launched. A umask of 026 is how we ended up with 751 permissions on a bunch of different things.