On 07/10/2014 07:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jul 10, 2014 at 06:43:26PM +0000, "Jóhann B. Guðmundsson" wrote:
On 07/10/2014 04:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jul 10, 2014 at 02:59:10PM +0000, "Jóhann B. Guðmundsson" wrote:
On 07/10/2014 12:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+ "/etc/sysusers.d\0"
+ "/run/sysusers.d\0"
"/usr/local/lib/sysusers.d\0"
"/usr/lib/sysusers.d\0"
#ifdef HAVE_SPLIT_USR
How does this handle multiple users and if I as an administrator I
wanted to block some users from being created I simply would not
have installed the component that created him in the first place no?
Let's say that mydatabase.rpm wants to use mydatabaseuser, and creates
the user using sysusers.d, and has a config file which contains
user = mydatabaseuser.
You as an admin know this, but want to use a different user for
whatever reason.
We need to know that reason as in what exactly is the problem
administrators is trying to solve by doing that and is that problem
not already solved with containers or sandboxed application?
The same justifications apply as with any other override in /etc...
Everything from testing, debugging to local setups and workarounds
for bugs in packaging or upstream.
Right which begs the question what's the solution to do administrative
overwrites for containers thus the suggestion for type container units.
JBG
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
