Bug #4384
closed
Rudder should enforce permissions when copying files from /usr/share/ncf to avoid permission error
Added by Nicolas PERRON over 10 years ago. Updated about 10 years ago.
Description
The ncf files are wrongly copied from the development folder /usr/share/ncf on the server and preserv wrong owner,group and mode into the folder /var/rudder/ncf on the server and nodes
ie: error displayed is
"error: File /var/rudder/ncf/common/service_mapping (owner 0) is writable by others (security exception)"
Updated by Nicolas PERRON over 10 years ago
- Status changed from New to Pending technical review
- Assignee set to Jonathan CLARKE
- % Done changed from 0 to 100
- Pull Request set to https://github.com/Normation/rudder-techniques/pull/275
Pull Request URL added: https://github.com/Normation/rudder-techniques/pull/275
Jon, could you review it please ?
Updated by Jonathan CLARKE over 10 years ago
- Status changed from Pending technical review to Discussion
- Assignee changed from Jonathan CLARKE to Nicolas PERRON
Thanks for reporting this. I understand the problem, but I don't really see why this was never noticed before - we tested this, and surely it would have come up... What has changed?
Either way, the approach you suggest to fix it will only fix this for Rudder! Why don't we simply change the installation perms in the ncf package?
Updated by Nicolas PERRON about 10 years ago
- Assignee changed from Nicolas PERRON to Jonathan CLARKE
Jonathan CLARKE wrote:
Thanks for reporting this. I understand the problem, but I don't really see why this was never noticed before - we tested this, and surely it would have come up... What has changed?
Either way, the approach you suggest to fix it will only fix this for Rudder! Why don't we simply change the installation perms in the ncf package?
This problem happen when the files in /usr/share/ncf are modified, not at the installation. And this is especially the case if we want to modify files remotely with several users with git.
After a discussion, it seems that the development folder is not /usr/share/ncf but /var/rudder/configuration-repository/ncf however if this is really the case, another bug appears: http://www.rudder-project.org/redmine/issues/4409
Updated by Jonathan CLARKE about 10 years ago
- Subject changed from If the files in /usr/share/ncf have not the restrictive mode, an error will occurs on server and nodes: "error: File /var/rudder/ncf/common/service_mapping (owner 0) is writable by others (security exception)" to Rudder should enforce permissions when copying files from /usr/share/ncf to avoid a "error: File /var/rudder/ncf/common/service_mapping (owner 0) is writable by others (security exception)" error
- Assignee changed from Jonathan CLARKE to Nicolas PERRON
- Priority changed from 1 to 4
Nicolas PERRON wrote:
Jonathan CLARKE wrote:
Thanks for reporting this. I understand the problem, but I don't really see why this was never noticed before - we tested this, and surely it would have come up... What has changed?
Either way, the approach you suggest to fix it will only fix this for Rudder! Why don't we simply change the installation perms in the ncf package?
This problem happen when the files in /usr/share/ncf are modified, not at the installation. And this is especially the case if we want to modify files remotely with several users with git.
After a discussion, it seems that the development folder is not /usr/share/ncf but /var/rudder/configuration-repository/ncf however if this is really the case, another bug appears: http://www.rudder-project.org/redmine/issues/4409
OK, let's look into #4409 which seems pretty problematic.
We agree that files under /usr/share/ncf should not be modified, so I've retargeted this bug to just enforce the permissions on the file copy, "just in case". Could you update the PR to just set permissions, without changing the paths that are copied from (or else explain why that would be necessary)? Thanks!
Updated by Nicolas PERRON about 10 years ago
- Category deleted (
System techniques) - Status changed from Discussion to Pending technical review
- Assignee changed from Nicolas PERRON to Jonathan CLARKE
- Priority changed from 4 to 1
Jonathan CLARKE wrote:
Nicolas PERRON wrote:
Jonathan CLARKE wrote:
Thanks for reporting this. I understand the problem, but I don't really see why this was never noticed before - we tested this, and surely it would have come up... What has changed?
Either way, the approach you suggest to fix it will only fix this for Rudder! Why don't we simply change the installation perms in the ncf package?
This problem happen when the files in /usr/share/ncf are modified, not at the installation. And this is especially the case if we want to modify files remotely with several users with git.
After a discussion, it seems that the development folder is not /usr/share/ncf but /var/rudder/configuration-repository/ncf however if this is really the case, another bug appears: http://www.rudder-project.org/redmine/issues/4409
OK, let's look into #4409 which seems pretty problematic.
We agree that files under /usr/share/ncf should not be modified, so I've retargeted this bug to just enforce the permissions on the file copy, "just in case". Could you update the PR to just set permissions, without changing the paths that are copied from (or else explain why that would be necessary)? Thanks!
Ok, PR updated.
Updated by Nicolas PERRON about 10 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset policy-templates:commit:aaa56aff61e09365c94b18ab2c1b11325d8de7f3.
Updated by Jonathan CLARKE about 10 years ago
Applied in changeset policy-templates:commit:214ed83bfb6b07a42c65df8f90959c7606bbdd8f.
Updated by Vincent MEMBRÉ about 10 years ago
- Subject changed from Rudder should enforce permissions when copying files from /usr/share/ncf to avoid a "error: File /var/rudder/ncf/common/service_mapping (owner 0) is writable by others (security exception)" error to Rudder should enforce permissions when copying files from /usr/share/ncf to avoid permission error
- Description updated (diff)
Updated by Vincent MEMBRÉ about 10 years ago
- Status changed from Pending release to Released
This bug has been fixed in Rudder 2.9.3, which was released today.
Check out:
- The release announcement: http://www.rudder-project.org/pipermail/rudder-announce/2014-March/000078.html
- The full ChangeLog: http://www.rudder-project.org/foswiki/bin/view/System/Documentation:ChangeLog29
- Download information: https://www.rudder-project.org/site/get-rudder/downloads/