Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 10/07/14 17:58 did gyre and gimble: On Thu, Jul 10, 2014 at 04:18:15PM +0100, Colin Guthrie wrote: I don't use RPM, but having your system's user policy consist of running useradd in a pre-installation script seems... sub-optimal. It is :) But sadly that's the way it's been done for a while, but now that there is a mechanism to decouple this from pre scripts, we'll be good. BTW., does anyone know what happened to the filetriggers idea [1]? Is it available in upstream rpm generally and/or in Fedora? It would be really nice to use this to avoid %post macros in every rpm using sysusers and tmpfiles. We've been using filetriggers in Mageia for a while. They certainly save a lot of %pre/%post cruft and while I've not yet moved tmpfiles over to them (originally calling --create without a config basename would create the /run/nologin file which meant a generic filetriggers was tricky, but you split that up a while back now and thus this is now possible), but certainly going to do so for sysusers! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 10:39:29PM +0200, Lennart Poettering wrote: Makes sense, commit! Done. (Also needs man page update I figure...) That was more work than the code change ;) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
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
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 10/07/14 13:51 did
gyre and gimble:
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
I guess this is probably OK, but isn't it a bit counter intuitive? I
mean one of the reasons for sysuser is due to /etc/ being bootstrapped.
In this case I'd have thought that looking in /etc/ is a bit weird.
What if you create a tmpfiles snippet to create a
/etc/sysusers.d/foo.conf file, does that mean we have to run tmpfiles
before sysusers?
But then I do accept that when sysusers is used for non-bootstrapping
(i.e. just instead of the %pre useradd in RPM scripts and the like) it
might be something an administrator would want to override. That said,
AFAIK, there is no way to override this current with rpm scripts, so I
wonder if this is really something to bother supporting ongoing.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
'Twas brillig, and Tobias Geerinckx-Rice at 10/07/14 15:53 did gyre and gimble: On 10 July 2014 13:41, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 10/07/14 13:51 did gyre and gimble: An administrator might want to block a certain sysusers config file from being executed, e.g. to block the creation of a certain user. I guess this is probably OK, but isn't it a bit counter intuitive? I mean one of the reasons for sysuser is due to /etc/ being bootstrapped. In this case I'd have thought that looking in /etc/ is a bit weird. Starting one's laptop in 2014 and seeing a new tape user added is also a bit weird :-) Although I'm running -git at the moment, not a distribution package, so maybe that's not what's supposed to happen. My first reaction was to create my own /etc/sysuser.d/basic.conf without it. Of course, that didn't work. Oh well. It wouldn't have been an ideal solution anyway, probably breaking future upgrades if the upstream basic.conf were to change. Well, this is a reasonable assumption overall I guess, especially considering the usual logic of overriding supported elsewhere in similar tools. It would only break things in future if basic.conf changed to have more essential users. I would suggest that we should put some of these standard, but legacy, users into a legacy.conf instead which should lessen the risk of future updates should you override it on your system (and assuming this patch is accepted!) But then I do accept that when sysusers is used for non-bootstrapping (i.e. just instead of the %pre useradd in RPM scripts and the like) it might be something an administrator would want to override. That said, AFAIK, there is no way to override this current with rpm scripts, so I wonder if this is really something to bother supporting ongoing. non-contributor tangent alert I don't use RPM, but having your system's user policy consist of running useradd in a pre-installation script seems... sub-optimal. It is :) But sadly that's the way it's been done for a while, but now that there is a mechanism to decouple this from pre scripts, we'll be good. (there is a small issue of ownership of certain files according to rpm - e.g. if the package wants to ship files that are user or group owned by users the package itself creates - but I suspect most of these cases will refer to files in /etc or /var both of which should be bootstrapable and thus have files fixed up by tmpfiles so it's likely not a huge issue practically speaking). Replacing this kind of distribution-level system user management -- if any -- with something remotely scalable still smells like a good idea. Yup, totally agree. I really like the sysusers.d stuff generally and look forward to cleaning up a lot of packages to get rid of these old %pre bits So does separating package-managed users/groups from administrator-managed ones: my /etc/groups currently contains openvpn, clamav and kvm, despite my having purged those packages ages ago. Why? I'm not convinced that users or admins, no matter how grey their beards, should be expected to manage such details *by default*. Well, the issue there is one of file ownership. Typically these users are created on installation but never purged on uninstall simply because files may have been stored using those users. e.g. /var/spool/clamav/virusmails/ might all be owned by clamav. If the user was purged when clamav was removed, all that data might sit there owned by the uid/gid (no longer attached to a named account). If then some other package is installed, and it creates a user account it *might* pick up the uid/gid vacated by clamav and thus suddenly become the owner of that data. This could obviously then be a vector for a data leak. That's the reasoning. There may be a better solution (such as scanning all files to find those owned by the uid/gid and deleting them on package removal), but this is the simplest - i.e. leave it to the admin! Having packages contain or depend on a sysusers.d/username.conf containing the relevant fields seems like a nice solution, with /etc then allowing full customisation. Or am I missing something obvious? Don't get me wrong, I really like sysusers.d/ It's just the slight chicken and egg thing that seems slightly odd! I'm not totally against this patch, but I do worry that it enables some weird corner cases when bootstrapping /etc/ from empty - but those are probably not big enough concerns to justify not accepting the patch! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
Am 10.07.2014 16:59, schrieb Jóhann B. Guðmundsson:
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?
you sound like it is always clear what package, probably installed as
dependency creates a user before - not speaking about that most packages
due uninstall don't remove the users created in rpm scripts
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 02:59:10PM +, 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. So you provide the config file, but sysusers will
still create the user. This is not harmful usually, but can lead
e.g. to confusion, if you or the other admin later sees that this
user exists. So you might do 'ln -s /dev/null /etc/sysusers.d/mydatabase.conf',
to avoid that.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On 07/10/2014 03:10 PM, Reindl Harald wrote:
Am 10.07.2014 16:59, schrieb Jóhann B. Guðmundsson:
On 07/10/2014 12:51 PM, Zbigniew Je;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?
you sound like it is always clear what package, probably installed as
dependency creates a user before - not speaking about that most packages
due uninstall don't remove the users created in rpm scripts
If you are an administrator you will quickly notice or do the necessary
research into what created the user that you dont want installed on your
system and take the necessary precaution from that happening again.
And arguable upstream should not be binding itself to solve downstream
distribution packaging problems be it rpm, be it deb or something else
since the installation scene is on the verge of changing...
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 02:41:14PM +0100, Colin Guthrie wrote: I guess this is probably OK, but isn't it a bit counter intuitive? I mean one of the reasons for sysuser is due to /etc/ being bootstrapped. In this case I'd have thought that looking in /etc/ is a bit weird. This probably wouldn't be useful for the case when /etc is bootstrapped, like you say below. What if you create a tmpfiles snippet to create a /etc/sysusers.d/foo.conf file, does that mean we have to run tmpfiles before sysusers? I think that's a bit of an artificial problem. Like with everything else, the outcome depends on the ordering. What would happen if tmpfiles.d were to create a .service file in /etc/systemd/system? Anyway, in this specific case, I believe sysusers should run before tmpfiles, so it is possible to use tmpfiles to create files owned by users created by sysusers. But then I do accept that when sysusers is used for non-bootstrapping (i.e. just instead of the %pre useradd in RPM scripts and the like) it might be something an administrator would want to override. That said, AFAIK, there is no way to override this current with rpm scripts, so I wonder if this is really something to bother supporting ongoing. Currently, even if you delete a user like this, there's no mechanism to prevent recreation on the next update of this or another unrelated package. So in some sense it is even worse, because with normal rpm scripts you are safe until this specific package is upgraded. But anyway, I find it very nice that the configuration loading mechanism is consistent between tools, and this inability to override sysusers is annoying. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 04:18:15PM +0100, Colin Guthrie wrote: I don't use RPM, but having your system's user policy consist of running useradd in a pre-installation script seems... sub-optimal. It is :) But sadly that's the way it's been done for a while, but now that there is a mechanism to decouple this from pre scripts, we'll be good. BTW., does anyone know what happened to the filetriggers idea [1]? Is it available in upstream rpm generally and/or in Fedora? It would be really nice to use this to avoid %post macros in every rpm using sysusers and tmpfiles. Zbyszek [1] https://wiki.mageia.org/en/RPM_filetriggers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On 07/10/2014 04:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jul 10, 2014 at 02:59:10PM +, 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?
So you provide the config file, but sysusers will
still create the user. This is not harmful usually, but can lead
e.g. to confusion, if you or the other admin later sees that this
user exists. So you might do 'ln -s /dev/null /etc/sysusers.d/mydatabase.conf',
to avoid that.
Surely Sandboxed applications when designed was not strictly intended
for GNOME or limited to Gnome existing on the machine for it to be used
mean surely I should be able to download/install/run the Sandboxed
applications postgresql which I fetched directly from postgresql
upstream and it's community and deploy it on my server
As I said before aren't we wasting time solving problems for packaging
formats that are becoming obsolete if things continue to progress in
sandboxed/containerized future?
I have to ask at this point is there something that is preventing us to
introduce type container unit?
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, Jul 10, 2014 at 06:43:26PM +, 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 +, 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.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On 07/10/2014 07:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jul 10, 2014 at 06:43:26PM +, 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 +, 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
Re: [systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run
On Thu, 10.07.14 14:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 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
Makes sense, commit!
(Also needs man page update I figure...)
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
