Hello,
we recently received following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1089098
Reporter is quite unhappy that setting access mode on sssd.conf to 0400 will result in SSSD's failure to start and error message requesting to set access mode to 0600.
Does it matter what access mode is set for user if it is required that user must be ROOT?
I didn't find out the original reason for requiring write permission for user so it possible that it is needless. But I'm afraid that simple changing the required access mode from 0600 to 0400 would cause failure to start SSSD for users who upgrade SSSD to newer version.
Maybe we can allow both modes (0400 and 0600) but is it worth doing?
Thank you for your opinions.
Pavel Reichl
On Fri, 2014-04-18 at 14:09 +0200, Pavel Reichl wrote:
Hello,
we recently received following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1089098
Reporter is quite unhappy that setting access mode on sssd.conf to 0400 will result in SSSD's failure to start and error message requesting to set access mode to 0600.
Does it matter what access mode is set for user if it is required that user must be ROOT?
I didn't find out the original reason for requiring write permission for user so it possible that it is needless. But I'm afraid that simple changing the required access mode from 0600 to 0400 would cause failure to start SSSD for users who upgrade SSSD to newer version.
Maybe we can allow both modes (0400 and 0600) but is it worth doing?
What we want to check here is that group/other do not have access.
The check should be: if ((stated_mode & 0077) != 0) { /* wrong perms */ }
Simo.
On Fri, Apr 18, 2014 at 02:09:33PM +0200, Pavel Reichl wrote:
Hello,
we recently received following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1089098
Reporter is quite unhappy that setting access mode on sssd.conf to 0400 will result in SSSD's failure to start and error message requesting to set access mode to 0600.
Does it matter what access mode is set for user if it is required that user must be ROOT?
I didn't find out the original reason for requiring write permission for user so it possible that it is needless. But I'm afraid that simple changing the required access mode from 0600 to 0400 would cause failure to start SSSD for users who upgrade SSSD to newer version.
Maybe we can allow both modes (0400 and 0600) but is it worth doing?
Thank you for your opinions.
I'll state the opinion I expressed in the bugzilla again -- we could reverse the check and instead ensure that group and others have no permission bits set, but I don't think it's worth doing, honestly.
Especially considering the tone the reporter chose in the bugzilla report.
On 04/18/2014 10:39 AM, Jakub Hrozek wrote:
On Fri, Apr 18, 2014 at 02:09:33PM +0200, Pavel Reichl wrote:
Hello,
we recently received following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1089098
Reporter is quite unhappy that setting access mode on sssd.conf to 0400 will result in SSSD's failure to start and error message requesting to set access mode to 0600.
Does it matter what access mode is set for user if it is required that user must be ROOT?
I didn't find out the original reason for requiring write permission for user so it possible that it is needless. But I'm afraid that simple changing the required access mode from 0600 to 0400 would cause failure to start SSSD for users who upgrade SSSD to newer version.
Maybe we can allow both modes (0400 and 0600) but is it worth doing?
Thank you for your opinions.
I'll state the opinion I expressed in the bugzilla again -- we could reverse the check and instead ensure that group and others have no permission bits set, but I don't think it's worth doing, honestly.
Especially considering the tone the reporter chose in the bugzilla report. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Let us focus on the core of the problem not on how it was conveyed. I think the reporter is right. I should not matter whether the file is writable by owner. The tone of the bug is a different problem and while I agree that the issue was expressed not in the best words it is still an issue.
On 19/04/14 17:18, Dmitri Pal wrote:
On 04/18/2014 10:39 AM, Jakub Hrozek wrote:
On Fri, Apr 18, 2014 at 02:09:33PM +0200, Pavel Reichl wrote:
Hello,
we recently received following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1089098
Reporter is quite unhappy that setting access mode on sssd.conf to 0400 will result in SSSD's failure to start and error message requesting to set access mode to 0600.
Does it matter what access mode is set for user if it is required that user must be ROOT?
I didn't find out the original reason for requiring write permission for user so it possible that it is needless. But I'm afraid that simple changing the required access mode from 0600 to 0400 would cause failure to start SSSD for users who upgrade SSSD to newer version.
Maybe we can allow both modes (0400 and 0600) but is it worth doing?
Thank you for your opinions.
I'll state the opinion I expressed in the bugzilla again -- we could reverse the check and instead ensure that group and others have no permission bits set, but I don't think it's worth doing, honestly.
Especially considering the tone the reporter chose in the bugzilla report. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Let us focus on the core of the problem not on how it was conveyed. I think the reporter is right. I should not matter whether the file is writable by owner. The tone of the bug is a different problem and while I agree that the issue was expressed not in the best words it is still an issue.
Can I offer my opinion here?
As long as the owner is root:root even if the permissions are 0400, root can still write to the file, so does it really matter if the permissions are 0600 or 0400 ? nobody else can read the file (or write to it) whatever the owners permissions are.
As for the tone of that bug report, well I think he needs a lesson in manners.
Rowland
On 04/19/2014 12:42 PM, Rowland Penny wrote:
On 19/04/14 17:18, Dmitri Pal wrote:
On 04/18/2014 10:39 AM, Jakub Hrozek wrote:
On Fri, Apr 18, 2014 at 02:09:33PM +0200, Pavel Reichl wrote:
Hello,
we recently received following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1089098
Reporter is quite unhappy that setting access mode on sssd.conf to 0400 will result in SSSD's failure to start and error message requesting to set access mode to 0600.
Does it matter what access mode is set for user if it is required that user must be ROOT?
I didn't find out the original reason for requiring write permission for user so it possible that it is needless. But I'm afraid that simple changing the required access mode from 0600 to 0400 would cause failure to start SSSD for users who upgrade SSSD to newer version.
Maybe we can allow both modes (0400 and 0600) but is it worth doing?
Thank you for your opinions.
I'll state the opinion I expressed in the bugzilla again -- we could reverse the check and instead ensure that group and others have no permission bits set, but I don't think it's worth doing, honestly.
Especially considering the tone the reporter chose in the bugzilla report. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Let us focus on the core of the problem not on how it was conveyed. I think the reporter is right. I should not matter whether the file is writable by owner. The tone of the bug is a different problem and while I agree that the issue was expressed not in the best words it is still an issue.
Can I offer my opinion here?
As long as the owner is root:root even if the permissions are 0400, root can still write to the file, so does it really matter if the permissions are 0600 or 0400 ? nobody else can read the file (or write to it) whatever the owners permissions are.
As for the tone of that bug report, well I think he needs a lesson in manners.
I agree with the above so I think 1) We should ignore the difference between 0600 and 0400 and start in both cases 2) Is teaching lessons what we are best at? ;-) Is it what we really should do? I would just give a sight and move on. Life is the best teacher...
Rowland
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Sat, 2014-04-19 at 13:31 -0400, Dmitri Pal wrote:
On 04/19/2014 12:42 PM, Rowland Penny wrote:
On 19/04/14 17:18, Dmitri Pal wrote:
On 04/18/2014 10:39 AM, Jakub Hrozek wrote:
On Fri, Apr 18, 2014 at 02:09:33PM +0200, Pavel Reichl wrote:
Hello,
we recently received following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1089098
Reporter is quite unhappy that setting access mode on sssd.conf to 0400 will result in SSSD's failure to start and error message requesting to set access mode to 0600.
Does it matter what access mode is set for user if it is required that user must be ROOT?
I didn't find out the original reason for requiring write permission for user so it possible that it is needless. But I'm afraid that simple changing the required access mode from 0600 to 0400 would cause failure to start SSSD for users who upgrade SSSD to newer version.
Maybe we can allow both modes (0400 and 0600) but is it worth doing?
Thank you for your opinions.
I'll state the opinion I expressed in the bugzilla again -- we could reverse the check and instead ensure that group and others have no permission bits set, but I don't think it's worth doing, honestly.
Especially considering the tone the reporter chose in the bugzilla report. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Let us focus on the core of the problem not on how it was conveyed. I think the reporter is right. I should not matter whether the file is writable by owner. The tone of the bug is a different problem and while I agree that the issue was expressed not in the best words it is still an issue.
Can I offer my opinion here?
As long as the owner is root:root even if the permissions are 0400, root can still write to the file, so does it really matter if the permissions are 0600 or 0400 ? nobody else can read the file (or write to it) whatever the owners permissions are.
As for the tone of that bug report, well I think he needs a lesson in manners.
I agree with the above so I think
- We should ignore the difference between 0600 and 0400 and start in
both cases
Patches attached.
Tested only with make check though.
- Is teaching lessons what we are best at? ;-) Is it what we really
should do? I would just give a sight and move on. Life is the best teacher...
Just ignore rude people ...
Btw: In master sbus_tests and sbus_codegen_tests, seem to be failing for me, but it is not related to these 2 patches.
Simo.
On Sat, 2014-04-19 at 17:23 -0400, Simo Sorce wrote:
Btw: In master sbus_tests and sbus_codegen_tests, seem to be failing for me, but it is not related to these 2 patches.
"Only" with make -jN where N>1. Tracked with: https://fedorahosted.org/sssd/ticket/2291
On Mon, 2014-04-21 at 23:23 +0200, Jakub Hrozek wrote:
On Sat, 2014-04-19 at 17:23 -0400, Simo Sorce wrote:
Btw: In master sbus_tests and sbus_codegen_tests, seem to be failing for me, but it is not related to these 2 patches.
"Only" with make -jN where N>1. Tracked with: https://fedorahosted.org/sssd/ticket/2291
unless N >1 is the default its not my case I guess, I did a normal `make && make check`
Simo.
On (22/04/14 08:40), Simo Sorce wrote:
On Mon, 2014-04-21 at 23:23 +0200, Jakub Hrozek wrote:
On Sat, 2014-04-19 at 17:23 -0400, Simo Sorce wrote:
Btw: In master sbus_tests and sbus_codegen_tests, seem to be failing for me, but it is not related to these 2 patches.
"Only" with make -jN where N>1. Tracked with: https://fedorahosted.org/sssd/ticket/2291
unless N >1 is the default its not my case I guess, I did a normal `make && make check`
Simo.
Could you send a log file from failed test? sbus_tests.log sbus_codegen_tests.log
LS
On Tue, 2014-04-22 at 20:43 +0200, Lukas Slebodnik wrote:
On (22/04/14 08:40), Simo Sorce wrote:
On Mon, 2014-04-21 at 23:23 +0200, Jakub Hrozek wrote:
On Sat, 2014-04-19 at 17:23 -0400, Simo Sorce wrote:
Btw: In master sbus_tests and sbus_codegen_tests, seem to be failing for me, but it is not related to these 2 patches.
"Only" with make -jN where N>1. Tracked with: https://fedorahosted.org/sssd/ticket/2291
unless N >1 is the default its not my case I guess, I did a normal `make && make check`
Simo.
Could you send a log file from failed test? sbus_tests.log sbus_codegen_tests.log
Yup, here they are in attachment.
Simo.
On Sat, 2014-04-19 at 17:23 -0400, Simo Sorce wrote:
On Sat, 2014-04-19 at 13:31 -0400, Dmitri Pal wrote:
On 04/19/2014 12:42 PM, Rowland Penny wrote:
On 19/04/14 17:18, Dmitri Pal wrote:
On 04/18/2014 10:39 AM, Jakub Hrozek wrote:
On Fri, Apr 18, 2014 at 02:09:33PM +0200, Pavel Reichl wrote:
Hello,
we recently received following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1089098
Reporter is quite unhappy that setting access mode on sssd.conf to 0400 will result in SSSD's failure to start and error message requesting to set access mode to 0600.
Does it matter what access mode is set for user if it is required that user must be ROOT?
I didn't find out the original reason for requiring write permission for user so it possible that it is needless. But I'm afraid that simple changing the required access mode from 0600 to 0400 would cause failure to start SSSD for users who upgrade SSSD to newer version.
Maybe we can allow both modes (0400 and 0600) but is it worth doing?
Thank you for your opinions.
I'll state the opinion I expressed in the bugzilla again -- we could reverse the check and instead ensure that group and others have no permission bits set, but I don't think it's worth doing, honestly.
Especially considering the tone the reporter chose in the bugzilla report. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Let us focus on the core of the problem not on how it was conveyed. I think the reporter is right. I should not matter whether the file is writable by owner. The tone of the bug is a different problem and while I agree that the issue was expressed not in the best words it is still an issue.
Can I offer my opinion here?
As long as the owner is root:root even if the permissions are 0400, root can still write to the file, so does it really matter if the permissions are 0600 or 0400 ? nobody else can read the file (or write to it) whatever the owners permissions are.
As for the tone of that bug report, well I think he needs a lesson in manners.
I agree with the above so I think
- We should ignore the difference between 0600 and 0400 and start in
both cases
Patches attached.
Tested only with make check though.
- Is teaching lessons what we are best at? ;-) Is it what we really
should do? I would just give a sight and move on. Life is the best teacher...
Just ignore rude people ...
Btw: In master sbus_tests and sbus_codegen_tests, seem to be failing for me, but it is not related to these 2 patches.
Simo.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Hello,
I tested the patches and they seem to me to be working flawlessly (so ACK to both).
I just noticed little nitpick: It was proposed:
What we want to check here is that group/other do not have access. The check should be: if ((stated_mode & 0077) != 0) { /* wrong perms */ }
but instead it is required for user to have permission to read and permissions to write and execute are optional. But I guess it doesn't really matter.
I have attached 2 patches fixing little issues of logging messages which I encountered during testing.
Pavel Reichl
On Tue, 2014-04-22 at 19:00 +0200, Pavel Reichl wrote:
Hello,
I tested the patches and they seem to me to be working flawlessly (so ACK to both).
I just noticed little nitpick: It was proposed:
What we want to check here is that group/other do not have access. The check should be: if ((stated_mode & 0077) != 0) { /* wrong perms */ }
but instead it is required for user to have permission to read and permissions to write and execute are optional. But I guess it doesn't really matter.
Thank you for testing, and yeah I decided to check at least for write permission, I think it is better to respect a lack of read permission which normally the root account would override.
I have attached 2 patches fixing little issues of logging messages which I encountered during testing.
See comments inline.
differences between files attachment (0001-Monitor-fix-message-wrong-perm.-mode-on-config-file.patch)
From b2e9350391a99085440e1b8ff816f0c72e72d14c Mon Sep 17 00:00:00 2001 From: Pavel Reichl reichl.pavel@gmail.com Date: Tue, 22 Apr 2014 14:40:05 +0100 Subject: [PATCH 1/2] Monitor: fix message wrong perm. mode on config file
Add missing new line in message. Add supporded access mode.
src/monitor/monitor.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c index 85655de75138ca35a18c09c961814191fd528e55..a7e6a8485debd27ed0d24b787f3f583a4487a333 100644 --- a/src/monitor/monitor.c +++ b/src/monitor/monitor.c @@ -86,8 +86,8 @@
/* Warning messages */ #define CONF_FILE_PERM_ERROR_MSG "Cannot read config file %s. Please check "\
"if permissions are 0600 and thefile is "\
"owned by root.root."
"if permissions are 0600 or 0400 andthe "\
"file is owned by root.root.\n"
Maybe we should change this to be something like: "Please check that the file is accessible only by the owner and owned by the root user."
Because technically all these will match: 0700, 0600, 0500, 0400. Listing them all seem excessive.
differences between files attachment (0002-util-Fix-file-mode-in-debug-message.patch)
From 186424590d617dd28ff28c8ca7d5dbb509d914a3 Mon Sep 17 00:00:00 2001 From: Pavel Reichl reichl.pavel@gmail.com Date: Tue, 22 Apr 2014 17:43:17 +0100 Subject: [PATCH 2/2] util: Fix file mode in debug message
src/util/check_and_open.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/check_and_open.c b/src/util/check_and_open.c index 80ec00e1023a05c3cf736b98ef27e61695766069..a6d0e09470027382991fe67888d366e82d282cf6 100644 --- a/src/util/check_and_open.c +++ b/src/util/check_and_open.c @@ -106,7 +106,7 @@ static errno_t perform_checks(struct stat *stat_buf, if ((st_mode & ALLPERMS) != (mode & ALLPERMS)) { DEBUG(SSSDBG_CRIT_FAILURE, "File has the wrong mode [%.7o], expected [%.7o].\n",
(st_mode & ALLPERMS), (mode & ALLPERMS));
(stat_buf->st_mode & ALLPERMS), (mode & ALLPERMS)); return EINVAL;
I am pretty sure st_mode & ALLPERMS is intentional, althugh I see it is debatable. If you want to show the original untouched mode I think you will also need then to print the mask, to make it clear what bits we really care for in mode.
Otherwise a file with st_mode of 0777 which we test against a mode of 0600 with a mask of 0622 (ie we care for it not being writable and we do not care if read or execute bits are set) would become confusing.
With my version we print: File has the wrong mode [0622], expected [0600] Yours would print: File has the wrong mode [0777], expected [0600]
So mine is not precise, but it tells you exactly what bits are out of place. Yours tells you what the file permissions actually are, but also tells you that you should chmod 600, when in reality chmod go-w would be sufficient.
I think mine would give a better clue, but I see possible confusion both ways ...
Simo.
On Tue, 2014-04-22 at 14:55 -0400, Simo Sorce wrote:
On Tue, 2014-04-22 at 19:00 +0200, Pavel Reichl wrote:
Hello,
I tested the patches and they seem to me to be working flawlessly (so ACK to both).
I just noticed little nitpick: It was proposed:
What we want to check here is that group/other do not have access. The check should be: if ((stated_mode & 0077) != 0) { /* wrong perms */ }
but instead it is required for user to have permission to read and permissions to write and execute are optional. But I guess it doesn't really matter.
Thank you for testing, and yeah I decided to check at least for write permission, I think it is better to respect a lack of read permission which normally the root account would override.
I have attached 2 patches fixing little issues of logging messages which I encountered during testing.
See comments inline.
differences between files attachment (0001-Monitor-fix-message-wrong-perm.-mode-on-config-file.patch)
From b2e9350391a99085440e1b8ff816f0c72e72d14c Mon Sep 17 00:00:00 2001 From: Pavel Reichl reichl.pavel@gmail.com Date: Tue, 22 Apr 2014 14:40:05 +0100 Subject: [PATCH 1/2] Monitor: fix message wrong perm. mode on config file
Add missing new line in message. Add supporded access mode.
src/monitor/monitor.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c index 85655de75138ca35a18c09c961814191fd528e55..a7e6a8485debd27ed0d24b787f3f583a4487a333 100644 --- a/src/monitor/monitor.c +++ b/src/monitor/monitor.c @@ -86,8 +86,8 @@
/* Warning messages */ #define CONF_FILE_PERM_ERROR_MSG "Cannot read config file %s. Please check "\
"if permissions are 0600 and thefile is "\
"owned by root.root."
"if permissions are 0600 or 0400 andthe "\
"file is owned by root.root.\n"Maybe we should change this to be something like: "Please check that the file is accessible only by the owner and owned by the root user."
Because technically all these will match: 0700, 0600, 0500, 0400. Listing them all seem excessive.
OK, 1st patch address this.
differences between files attachment (0002-util-Fix-file-mode-in-debug-message.patch)
From 186424590d617dd28ff28c8ca7d5dbb509d914a3 Mon Sep 17 00:00:00 2001 From: Pavel Reichl reichl.pavel@gmail.com Date: Tue, 22 Apr 2014 17:43:17 +0100 Subject: [PATCH 2/2] util: Fix file mode in debug message
src/util/check_and_open.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/check_and_open.c b/src/util/check_and_open.c index 80ec00e1023a05c3cf736b98ef27e61695766069..a6d0e09470027382991fe67888d366e82d282cf6 100644 --- a/src/util/check_and_open.c +++ b/src/util/check_and_open.c @@ -106,7 +106,7 @@ static errno_t perform_checks(struct stat *stat_buf, if ((st_mode & ALLPERMS) != (mode & ALLPERMS)) { DEBUG(SSSDBG_CRIT_FAILURE, "File has the wrong mode [%.7o], expected [%.7o].\n",
(st_mode & ALLPERMS), (mode & ALLPERMS));
(stat_buf->st_mode & ALLPERMS), (mode & ALLPERMS)); return EINVAL;I am pretty sure st_mode & ALLPERMS is intentional, althugh I see it is debatable. If you want to show the original untouched mode I think you will also need then to print the mask, to make it clear what bits we really care for in mode.
Otherwise a file with st_mode of 0777 which we test against a mode of 0600 with a mask of 0622 (ie we care for it not being writable and we do not care if read or execute bits are set) would become confusing.
With my version we print: File has the wrong mode [0622], expected [0600] Yours would print: File has the wrong mode [0777], expected [0600]
So mine is not precise, but it tells you exactly what bits are out of place. Yours tells you what the file permissions actually are, but also tells you that you should chmod 600, when in reality chmod go-w would be sufficient.
I think mine would give a better clue, but I see possible confusion both ways ...
Simo.
Oh I see now, I believe your solution is better. 2nd attached patch just rewords the message to give a clue about bit mask being used.
File has the wrong (bit masked) mode [0622], expected [0600] ^^^^^^^^^^^ But I'm not sure if it is not even more confusing. :-)
On Wed, 2014-04-23 at 11:25 +0200, Pavel Reichl wrote:
On Tue, 2014-04-22 at 14:55 -0400, Simo Sorce wrote:
On Tue, 2014-04-22 at 19:00 +0200, Pavel Reichl wrote:
Hello,
I tested the patches and they seem to me to be working flawlessly (so ACK to both).
I just noticed little nitpick: It was proposed:
What we want to check here is that group/other do not have access. The check should be: if ((stated_mode & 0077) != 0) { /* wrong perms */ }
but instead it is required for user to have permission to read and permissions to write and execute are optional. But I guess it doesn't really matter.
Thank you for testing, and yeah I decided to check at least for write permission, I think it is better to respect a lack of read permission which normally the root account would override.
I have attached 2 patches fixing little issues of logging messages which I encountered during testing.
See comments inline.
differences between files attachment (0001-Monitor-fix-message-wrong-perm.-mode-on-config-file.patch)
From b2e9350391a99085440e1b8ff816f0c72e72d14c Mon Sep 17 00:00:00 2001 From: Pavel Reichl reichl.pavel@gmail.com Date: Tue, 22 Apr 2014 14:40:05 +0100 Subject: [PATCH 1/2] Monitor: fix message wrong perm. mode on config file
Add missing new line in message. Add supporded access mode.
src/monitor/monitor.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c index 85655de75138ca35a18c09c961814191fd528e55..a7e6a8485debd27ed0d24b787f3f583a4487a333 100644 --- a/src/monitor/monitor.c +++ b/src/monitor/monitor.c @@ -86,8 +86,8 @@
/* Warning messages */ #define CONF_FILE_PERM_ERROR_MSG "Cannot read config file %s. Please check "\
"if permissions are 0600 and thefile is "\
"owned by root.root."
"if permissions are 0600 or 0400 andthe "\
"file is owned by root.root.\n"Maybe we should change this to be something like: "Please check that the file is accessible only by the owner and owned by the root user."
Because technically all these will match: 0700, 0600, 0500, 0400. Listing them all seem excessive.
OK, 1st patch address this.
Ack with nit pick: "by the root.root" -> "by root.root"
Oh I see now, I believe your solution is better. 2nd attached patch just rewords the message to give a clue about bit mask being used.
File has the wrong (bit masked) mode [0622], expected [0600] ^^^^^^^^^^^ But I'm not sure if it is not even more confusing. :-)
It is fine, ACK.
Simo.
On Wed, 2014-04-23 at 09:06 -0400, Simo Sorce wrote: [snip]
Ack with nit pick: "by the root.root" -> "by root.root"
Oh I see now, I believe your solution is better. 2nd attached patch just rewords the message to give a clue about bit mask being used.
File has the wrong (bit masked) mode [0622], expected [0600] ^^^^^^^^^^^ But I'm not sure if it is not even more confusing. :-)
It is fine, ACK.
Simo.
Thanks, nitpick addressed.
On Wed, Apr 23, 2014 at 03:30:11PM +0200, Pavel Reichl wrote:
On Wed, 2014-04-23 at 09:06 -0400, Simo Sorce wrote: [snip]
Ack with nit pick: "by the root.root" -> "by root.root"
Oh I see now, I believe your solution is better. 2nd attached patch just rewords the message to give a clue about bit mask being used.
File has the wrong (bit masked) mode [0622], expected [0600] ^^^^^^^^^^^ But I'm not sure if it is not even more confusing. :-)
It is fine, ACK.
Simo.
Thanks, nitpick addressed.
I think Simo's concerns have been addressed.
ACK from me as well.
On Mon, Apr 28, 2014 at 10:07:30PM +0200, Jakub Hrozek wrote:
On Wed, Apr 23, 2014 at 03:30:11PM +0200, Pavel Reichl wrote:
On Wed, 2014-04-23 at 09:06 -0400, Simo Sorce wrote: [snip]
Ack with nit pick: "by the root.root" -> "by root.root"
Oh I see now, I believe your solution is better. 2nd attached patch just rewords the message to give a clue about bit mask being used.
File has the wrong (bit masked) mode [0622], expected [0600] ^^^^^^^^^^^ But I'm not sure if it is not even more confusing. :-)
It is fine, ACK.
Simo.
Thanks, nitpick addressed.
I think Simo's concerns have been addressed.
ACK from me as well.
Pushed to master: da7d1fde3f9e37600831bdd5674291522fabd6f2 994dd4bdb6d3f320ea26853169474e20353c636d
On Tue, Apr 22, 2014 at 07:00:38PM +0200, Pavel Reichl wrote:
On Sat, 2014-04-19 at 17:23 -0400, Simo Sorce wrote:
On Sat, 2014-04-19 at 13:31 -0400, Dmitri Pal wrote:
On 04/19/2014 12:42 PM, Rowland Penny wrote:
On 19/04/14 17:18, Dmitri Pal wrote:
On 04/18/2014 10:39 AM, Jakub Hrozek wrote:
On Fri, Apr 18, 2014 at 02:09:33PM +0200, Pavel Reichl wrote: > Hello, > > we recently received following bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=1089098 > > Reporter is quite unhappy that setting access mode on sssd.conf to > 0400 > will result in SSSD's failure to start and error message requesting to > set access mode to 0600. > > Does it matter what access mode is set for user if it is required that > user must be ROOT? > > I didn't find out the original reason for requiring write > permission for > user so it possible that it is needless. But I'm afraid that simple > changing the required access mode from 0600 to 0400 would cause > failure > to start SSSD for users who upgrade SSSD to newer version. > > Maybe we can allow both modes (0400 and 0600) but is it worth doing? > > Thank you for your opinions. I'll state the opinion I expressed in the bugzilla again -- we could reverse the check and instead ensure that group and others have no permission bits set, but I don't think it's worth doing, honestly.
Especially considering the tone the reporter chose in the bugzilla report. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Let us focus on the core of the problem not on how it was conveyed. I think the reporter is right. I should not matter whether the file is writable by owner. The tone of the bug is a different problem and while I agree that the issue was expressed not in the best words it is still an issue.
Can I offer my opinion here?
As long as the owner is root:root even if the permissions are 0400, root can still write to the file, so does it really matter if the permissions are 0600 or 0400 ? nobody else can read the file (or write to it) whatever the owners permissions are.
As for the tone of that bug report, well I think he needs a lesson in manners.
I agree with the above so I think
- We should ignore the difference between 0600 and 0400 and start in
both cases
Patches attached.
Tested only with make check though.
- Is teaching lessons what we are best at? ;-) Is it what we really
should do? I would just give a sight and move on. Life is the best teacher...
Just ignore rude people ...
Btw: In master sbus_tests and sbus_codegen_tests, seem to be failing for me, but it is not related to these 2 patches.
Simo.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Hello,
I tested the patches and they seem to me to be working flawlessly (so ACK to both).
Pushed to master: a5f79cce8abc74beec0c27c477c046bb6cbe7101 9a592ee3fc195f20732c6b1f90894a0be25ccc19
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Jakub Hrozek -
Lukas Slebodnik -
Pavel Reichl -
Rowland Penny -
Simo Sorce