Re: [systemd-devel] systemd-sysusers

[Roman Mingazeev]

Of course, we understand, that it must create a system users. But, we hope do it via just systemd.We think use adduser/addgroup and deluser/delgroup is "ugly"09.07.2018, 10:20, "Mantas Mikulėnas" :On Mon, Jul 9, 2018 at 6:33 AM Roman Mingazeev  wrote:Hello, can you help?
1) Is there any possibility to implement to add and remove users/groups via systemd-sysusers ?Addition is already implemented (I mean, that's the whole point)... removal *probably* won't be, as it could very easily lead to UID collisions (e.g. you remove an account which had UID 994, and then a week later you add a different account with UID 994).Note that sysusers is meant for *system* accounts (daemons, services, etc.) – not for human accounts. 
2) And where is systemd-sysusers.service? (Or why it is in man)It's in the same place as other default services. Try `systemctl cat` or `systemctl status` and it'll show the path. (Assuming your distro hasn't removed the service entirely, that is...) 
3) Can I sync uid:gid on different machinesFor human accounts? In general, the service isn't meant for that. Deploying a sysusers config with static UIDs to all your machines would work, but I'd say it's overkill – after all, you could just use the same configuration deploy mechanism to add accounts directly. Most sites use LDAP or NIS for that purpose.-- Mantas Mikulėnas

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Mantas Mikulėnas]

On Mon, Jul 9, 2018 at 6:33 AM Roman Mingazeev  wrote:

> Hello, can you help?
> 1) Is there any possibility to implement to add and remove users/groups
> via systemd-sysusers ?
>

Addition is already implemented (I mean, that's the whole point)... removal
*probably* won't be, as it could very easily lead to UID collisions (e.g.
you remove an account which had UID 994, and then a week later you add a
different account with UID 994).

Note that sysusers is meant for *system* accounts (daemons, services, etc.)
– not for human accounts.


> 2) And where is systemd-sysusers.service? (Or why it is in man)
>

It's in the same place as other default services. Try `systemctl cat` or
`systemctl status` and it'll show the path. (Assuming your distro hasn't
removed the service entirely, that is...)


> 3) Can I sync uid:gid on different machines
>

For human accounts? In general, the service isn't meant for that. Deploying
a sysusers config with static UIDs to all your machines would work, but I'd
say it's overkill – after all, you could just use the same configuration
deploy mechanism to add accounts directly. Most sites use LDAP or NIS for
that purpose.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Lennart Poettering]

On Mo, 05.02.18 10:21, Johannes Ernst (johannes.er...@gmail.com) wrote:

> >> It appears systemd-sysusers does not create home directories. On
> >> the other hand, it picks (largely unpredictable) UIDs from a
> >> range.
> >> 
> >> So I have to run systemd-sysusers, and after that, find the UID
> >> of the user and chown the home directory? Or is there the
> >> equivalent of the “useradd -m” flag somewhere that I’m just not
> >> seeing?
> > 
> > systemd-sysusers is, as the name suggests, really for _system_
> > users, and often those kinds of users don't have ordinary home
> > directories -- that is, ones the user can actually write to.
> 
> I agree with the “often” but not more :-)
> 
> > However, systemd-sysusers.service is ordered before
> > systemd-tmpfiles-setup.service at boot, so if you need to create a
> > system user's home directory and ensure its ownership is correct,
> > you could use a corresponding tmpfiles.d fragment to do so.
> 
> Hmm … tmpfiles.d, according to its man page, is for “the creation,
> cleaning and removal of volatile and temporary files and directories
> which usually reside in directories such as /run or /tmp.”. That
> doesn’t really seem to cover home directories that contain actual
> data.
> 
> Here’s my use case: Take a package for a daemon foo. The package
> contains a foo.service, and when foo runs, it is supposed to run in
> its own little place /var/lib/foo where it stores its data
> files. Because not everybody runs foo, it doesn’t make sense to pick
> a “fixed” UID like for more common daemons. Allocating a UID from a
> pool, like sysusers does, seems perfect. But how does the package
> ship /var/lib/foo? It can’t ship with owner foo because we don’t
> know what its UID is going to be. So the package, as part of its
> install script, needs to do something like:

My recommendation: simply use StateDirectory=foo in the service's unit
file (along with User=foo) to make things simpler and more robust. In
that case the directory is created automatically when the service is
started first, and chown()ed to the selected user. Note that this
works even if your service wants to drop privs on its own, because in
that case you can prefix its ExecStart= command line with "!", which
disables systemd's UID dropping code for that line. That way you can
safely declare a user in a service so that StateDirectory= has the
right ownership without this also implying systemd drops privs for
you.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 05, 2018 at 10:21:17AM -0800, Johannes Ernst wrote:
> 
> > On Feb 4, 2018, at 21:56, Michael Chapman  wrote:
> > 
> > On Mon, 5 Feb 2018, Johannes Ernst wrote:
> >> It appears systemd-sysusers does not create home directories. On the other 
> >> hand, it picks (largely unpredictable) UIDs from a range.
> >> 
> >> So I have to run systemd-sysusers, and after that, find the UID of the 
> >> user and chown the home directory? Or is there the equivalent of the 
> >> “useradd -m” flag somewhere that I’m just not seeing?
> > 
> > systemd-sysusers is, as the name suggests, really for _system_ users, and 
> > often those kinds of users don't have ordinary home directories -- that is, 
> > ones the user can actually write to.
> 
> I agree with the “often” but not more :-)
> 
> > However, systemd-sysusers.service is ordered before 
> > systemd-tmpfiles-setup.service at boot, so if you need to create a system 
> > user's home directory and ensure its ownership is correct, you could use a 
> > corresponding tmpfiles.d fragment to do so.
> 
> Hmm … tmpfiles.d, according to its man page, is for “the creation, cleaning 
> and removal of volatile and temporary files and directories which usually 
> reside in directories such as /run or /tmp.”. That doesn’t really seem to 
> cover home directories that contain actual data.
> 
> Here’s my use case: Take a package for a daemon foo. The package contains a 
> foo.service, and when foo runs, it is supposed to run in its own little place 
> /var/lib/foo where it stores its data files. Because not everybody runs foo, 
> it doesn’t make sense to pick a “fixed” UID like for more common daemons. 
> Allocating a UID from a pool, like sysusers does, seems perfect. But how does 
> the package ship /var/lib/foo? It can’t ship with owner foo because we don’t 
> know what its UID is going to be. So the package, as part of its install 
> script, needs to do something like:
> 
> systemd-sysusers
> [[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
> chown $(id -u foo):$(id -g foo) /var/lib/foo

# /usr/lib/tmpfiles.d/foo.conf
d /var/lib/foo 0755 foo foo -

(BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo ...).

Zbyszek

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Reindl Harald]

Am 05.02.2018 um 19:35 schrieb Johannes Ernst:

On Feb 5, 2018, at 10:31, Zbigniew Jędrzejewski-Szmek  wrote:





systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo


# /usr/lib/tmpfiles.d/foo.conf
d /var/lib/foo 0755 foo foo -

(BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo …).


Good point :-)

If so, the wording in man systemd-tmpfiles.d is still rather discouraging to 
people like me to do it this way because it very clearly talks about 
“temporary” files


because the stuff in /tmp and especially /run *is* temporary based on 
the nature of tmpfs

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Johannes Ernst]

> On Feb 5, 2018, at 10:31, Zbigniew Jędrzejewski-Szmek  
> wrote:



>> systemd-sysusers
>> [[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
>> chown $(id -u foo):$(id -g foo) /var/lib/foo
> 
> # /usr/lib/tmpfiles.d/foo.conf
> d /var/lib/foo 0755 foo foo -
> 
> (BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo …).

Good point :-)

If so, the wording in man systemd-tmpfiles.d is still rather discouraging to 
people like me to do it this way because it very clearly talks about 
“temporary” files.

Thanks,



Johannes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Johannes Ernst]

> On Feb 4, 2018, at 21:56, Michael Chapman  wrote:
> 
> On Mon, 5 Feb 2018, Johannes Ernst wrote:
>> It appears systemd-sysusers does not create home directories. On the other 
>> hand, it picks (largely unpredictable) UIDs from a range.
>> 
>> So I have to run systemd-sysusers, and after that, find the UID of the user 
>> and chown the home directory? Or is there the equivalent of the “useradd -m” 
>> flag somewhere that I’m just not seeing?
> 
> systemd-sysusers is, as the name suggests, really for _system_ users, and 
> often those kinds of users don't have ordinary home directories -- that is, 
> ones the user can actually write to.

I agree with the “often” but not more :-)

> However, systemd-sysusers.service is ordered before 
> systemd-tmpfiles-setup.service at boot, so if you need to create a system 
> user's home directory and ensure its ownership is correct, you could use a 
> corresponding tmpfiles.d fragment to do so.

Hmm … tmpfiles.d, according to its man page, is for “the creation, cleaning and 
removal of volatile and temporary files and directories which usually reside in 
directories such as /run or /tmp.”. That doesn’t really seem to cover home 
directories that contain actual data.

Here’s my use case: Take a package for a daemon foo. The package contains a 
foo.service, and when foo runs, it is supposed to run in its own little place 
/var/lib/foo where it stores its data files. Because not everybody runs foo, it 
doesn’t make sense to pick a “fixed” UID like for more common daemons. 
Allocating a UID from a pool, like sysusers does, seems perfect. But how does 
the package ship /var/lib/foo? It can’t ship with owner foo because we don’t 
know what its UID is going to be. So the package, as part of its install 
script, needs to do something like:

systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo

I’d rather prefer a flag (if not the default) in the .conf file saying “create 
directory if it does not exist”. Perhaps worth adding?

But thanks for confirming that I didn’t miss anything, and I indeed need to 
jump through this hoop.

Cheers,



Johannes.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Reindl Harald]

Am 05.02.2018 um 10:47 schrieb Michael Chapman:

On Mon, 5 Feb 2018, Reindl Harald wrote:

Am 05.02.2018 um 06:56 schrieb Michael Chapman:

 On Mon, 5 Feb 2018, Johannes Ernst wrote:

 It appears systemd-sysusers does not create home directories. On the
 other hand, it picks (largely unpredictable) UIDs from a range.

 So I have to run systemd-sysusers, and after that, find the UID of the
 user and chown the home directory? Or is there the equivalent of the
 “useradd -m” flag somewhere that I’m just not seeing?


 systemd-sysusers is, as the name suggests, really for _system_ 
users, and

 often those kinds of users don't have ordinary home directories -- that
 is, ones the user can actually write to.

 However, systemd-sysusers.service is ordered before
 systemd-tmpfiles-setup.service at boot, so if you need to create a 
system
 user's home directory and ensure its ownership is correct, you could 
use a

 corresponding tmpfiles.d fragment to do so.


i hope you meant systemd-tmpfiles-setup.service is ordered before 
systemd-sysusers.service and you simply talked about "Before=" which 
in fact means ordered after


Sorry, I cannot work out what you are saying.

Take a look at the unit files as shipped in systemd. 
systemd-tmpfiles-setup.service is ordered After=systemd-sysusers.service 
(which is, as far as I can tell, equivalent to what I said before). It 
needs to be that way around for a tmpfiles.d fragment to be able to 
reference a user created by systemd-sysusers.


buffer overflow - coffee missing - sorry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Michael Chapman]

On Mon, 5 Feb 2018, Reindl Harald wrote:

Am 05.02.2018 um 06:56 schrieb Michael Chapman:

 On Mon, 5 Feb 2018, Johannes Ernst wrote:

 It appears systemd-sysusers does not create home directories. On the
 other hand, it picks (largely unpredictable) UIDs from a range.

 So I have to run systemd-sysusers, and after that, find the UID of the
 user and chown the home directory? Or is there the equivalent of the
 “useradd -m” flag somewhere that I’m just not seeing?


 systemd-sysusers is, as the name suggests, really for _system_ users, and
 often those kinds of users don't have ordinary home directories -- that
 is, ones the user can actually write to.

 However, systemd-sysusers.service is ordered before
 systemd-tmpfiles-setup.service at boot, so if you need to create a system
 user's home directory and ensure its ownership is correct, you could use a
 corresponding tmpfiles.d fragment to do so.


i hope you meant systemd-tmpfiles-setup.service is ordered before 
systemd-sysusers.service and you simply talked about "Before=" which in fact 
means ordered after


Sorry, I cannot work out what you are saying.

Take a look at the unit files as shipped in systemd. 
systemd-tmpfiles-setup.service is ordered After=systemd-sysusers.service 
(which is, as far as I can tell, equivalent to what I said before). It 
needs to be that way around for a tmpfiles.d fragment to be able to 
reference a user created by systemd-sysusers.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Mantas Mikulėnas]

On Mon, Feb 5, 2018 at 11:26 AM, Reindl Harald 
wrote:

>
>
> Am 05.02.2018 um 06:56 schrieb Michael Chapman:
>
>> On Mon, 5 Feb 2018, Johannes Ernst wrote:
>>
>>> It appears systemd-sysusers does not create home directories. On the
>>> other hand, it picks (largely unpredictable) UIDs from a range.
>>>
>>> So I have to run systemd-sysusers, and after that, find the UID of the
>>> user and chown the home directory? Or is there the equivalent of the
>>> “useradd -m” flag somewhere that I’m just not seeing?
>>>
>>
>> systemd-sysusers is, as the name suggests, really for _system_ users, and
>> often those kinds of users don't have ordinary home directories -- that is,
>> ones the user can actually write to.
>>
>> However, systemd-sysusers.service is ordered before
>> systemd-tmpfiles-setup.service at boot, so if you need to create a system
>> user's home directory and ensure its ownership is correct, you could use a
>> corresponding tmpfiles.d fragment to do so.
>>
>
> i hope you meant systemd-tmpfiles-setup.service is ordered before
> systemd-sysusers.service and you simply talked about "Before=" which in
> fact means ordered after


"Before=" means before. "After=" means after. If Unit A has "After=B", then
A is ordered after B.

$ systemctl cat systemd-tmpfiles-setup.service
# /usr/lib/systemd/system/systemd-tmpfiles-setup.service
…
[Unit]
Description=Create Volatile Files and Directories
Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)
DefaultDependencies=no
Conflicts=shutdown.target
*After=local-fs.target systemd-sysusers.service*


-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Reindl Harald]

Am 05.02.2018 um 06:56 schrieb Michael Chapman:

On Mon, 5 Feb 2018, Johannes Ernst wrote:
It appears systemd-sysusers does not create home directories. On the 
other hand, it picks (largely unpredictable) UIDs from a range.


So I have to run systemd-sysusers, and after that, find the UID of the 
user and chown the home directory? Or is there the equivalent of the 
“useradd -m” flag somewhere that I’m just not seeing?


systemd-sysusers is, as the name suggests, really for _system_ users, 
and often those kinds of users don't have ordinary home directories -- 
that is, ones the user can actually write to.


However, systemd-sysusers.service is ordered before 
systemd-tmpfiles-setup.service at boot, so if you need to create a 
system user's home directory and ensure its ownership is correct, you 
could use a corresponding tmpfiles.d fragment to do so.


i hope you meant systemd-tmpfiles-setup.service is ordered before 
systemd-sysusers.service and you simply talked about "Before=" which in 
fact means ordered after


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Michael Chapman]

On Mon, 5 Feb 2018, Johannes Ernst wrote:
It appears systemd-sysusers does not create home directories. On the 
other hand, it picks (largely unpredictable) UIDs from a range.


So I have to run systemd-sysusers, and after that, find the UID of the 
user and chown the home directory? Or is there the equivalent of the 
“useradd -m” flag somewhere that I’m just not seeing?


systemd-sysusers is, as the name suggests, really for _system_ users, and 
often those kinds of users don't have ordinary home directories -- that 
is, ones the user can actually write to.


However, systemd-sysusers.service is ordered before 
systemd-tmpfiles-setup.service at boot, so if you need to create a system 
user's home directory and ensure its ownership is correct, you could use a 
corresponding tmpfiles.d fragment to do so.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers does not create nobody user

[Sébastien Luttringer]

On Tue, 2017-09-12 at 13:26 +0200, Lennart Poettering wrote:
> On Mo, 11.09.17 23:33, Sébastien Luttringer (se...@seblu.net) wrote:
> 
> > Hello,
> > 
> > It appears that the nobody user/group are not created by systemd-sysusers,
> > despite its definition in sysusers.d/basic.conf.
> > I guess nss_systemd is always providing answers for nobody user/group which
> > mislead systemd-sysusers.
> > 
> > # grep nobody /etc/passwd; echo $?
> > 1
> > # getent passwd nobody
> > nobody:*:65534:65534:User Nobody:/:/sbin/nologin
> > # SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/basic.conf
> > Group nobody already exists.
> > User nobody already exists.
> > 
> > I guess the issue is the same for root user.
> > For reference, this come from this bug report: https://bugs.archlinux.org/t
> > ask/
> > 55589
> > 
> > A side effect, may segfault sshd. See: https://bugs.archlinux.org/task/5557
> > 0
> > 
> > I tend to think that systemd-users should be able to start working with and
> > empty passwd/group.
> > What do you think is the correct way to fix these two? 
> 
> Ouch! This sounds like a systemd bug indeed. Could you please file a
> bug on github about this? 
> 
> Lennart
> 

Sure. Done here: https://github.com/systemd/systemd/issues/6808
Cheers,

Sébastien "Seblu" Luttringer



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers does not create nobody user

[Lennart Poettering]

On Mo, 11.09.17 23:33, Sébastien Luttringer (se...@seblu.net) wrote:

> Hello,
> 
> It appears that the nobody user/group are not created by systemd-sysusers,
> despite its definition in sysusers.d/basic.conf.
> I guess nss_systemd is always providing answers for nobody user/group which
> mislead systemd-sysusers.
> 
> # grep nobody /etc/passwd; echo $?
> 1
> # getent passwd nobody
> nobody:*:65534:65534:User Nobody:/:/sbin/nologin
> # SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/basic.conf
> Group nobody already exists.
> User nobody already exists.
> 
> I guess the issue is the same for root user.
> For reference, this come from this bug report: 
> https://bugs.archlinux.org/task/
> 55589
> 
> A side effect, may segfault sshd. See: https://bugs.archlinux.org/task/55570
> 
> I tend to think that systemd-users should be able to start working with and
> empty passwd/group.
> What do you think is the correct way to fix these two? 

Ouch! This sounds like a systemd bug indeed. Could you please file a
bug on github about this? 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers and gshadow

[Lennart Poettering]

On Sun, 06.07.14 19:17, Leonid Isaev (lis...@umail.iu.edu) wrote:

 Hi,
 
   Shouldn't systemd-sysusers update /etc/gshadow when adding 'basic'
 groups? From sysusers.c I don't see that gshadow (and shadow) is updated, and
 this seems to cause problems on package updates. Consider the following
 scenario:
 1. A package is updated, so timestamp of /usr gets ahead of /etc/.updated.
 2. On next boot, new groups are added to /etc/group. In the case of archlinux
 these are dialout, tape and cdrom -- which I had to manually groupdel.
 3. gshadow is out-of-sync with group, so routine cron-based grpck
 fails.

Well, the reason we don't bother with /etc/shadow and /etc/gshadow, is
that we didnt want to set any password for the accounts sysusers
creates. And no matching entry in these files means that an account
doesn't have any password set, and cannot be used for login.

I wasn#t aware of grpck, and quite frankly  don't think it makes much
sense, what the tool is doing.

But anyway, fixing sysusers to also add the users to shadow and gshadow
should be trivial (well, for gshadow there's no API in glibc to write
these files...)

 Does it mean that on each update, a package manager should touch
 /etc/.updated?

Hmm? No. A package manager should touch /usr after having done its work.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers and gshadow

[Leonid Isaev]

Hi,

Thanks for the explanation...

On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote:
 I wasn#t aware of grpck, and quite frankly  don't think it makes much
 sense, what the tool is doing.

Why? Checking syntax can never hurt...

  Does it mean that on each update, a package manager should touch
  /etc/.updated?
 
 Hmm? No. A package manager should touch /usr after having done its work.

Just to see if I understand: this would mean that ConditionNeedsUpdate = .true.
for /etc, no? So, we _do_ want systemd-sysusers.service, ldconfig.service, et
al. to run on next boot after an update?

Thanks,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


pgpbpZbXN3pTQ.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers and gshadow

[Lennart Poettering]

On Mon, 07.07.14 11:08, Leonid Isaev (lis...@umail.iu.edu) wrote:

 Hi,
 
   Thanks for the explanation...
 
 On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote:
  I wasn#t aware of grpck, and quite frankly  don't think it makes much
  sense, what the tool is doing.
 
 Why? Checking syntax can never hurt...

Well, I am not opposed to that. I am just saying that otherwise the
current logic so nicely considers an account with a missing counterpart
in /etc/shadow disabled with no way to log in, which is exactly what we
want here. However, grpck tool breaks that...

   Does it mean that on each update, a package manager should touch
   /etc/.updated?
  
  Hmm? No. A package manager should touch /usr after having done its work.
 
 Just to see if I understand: this would mean that ConditionNeedsUpdate = 
 .true.
 for /etc, no? So, we _do_ want systemd-sysusers.service, ldconfig.service, et
 al. to run on next boot after an update?

Well, the idea is that they are NOPs if they already ran from postinst...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers and gshadow

[Leonid Isaev]

On Mon, Jul 07, 2014 at 05:40:42PM +0200, Lennart Poettering wrote:
 On Mon, 07.07.14 11:08, Leonid Isaev (lis...@umail.iu.edu) wrote:
 
  Hi,
  
  Thanks for the explanation...
  
  On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote:
   I wasn#t aware of grpck, and quite frankly  don't think it makes much
   sense, what the tool is doing.
  
  Why? Checking syntax can never hurt...
 
 Well, I am not opposed to that. I am just saying that otherwise the
 current logic so nicely considers an account with a missing counterpart
 in /etc/shadow disabled with no way to log in, which is exactly what we
 want here. However, grpck tool breaks that...

Ah, right. So you mean grpck _and_ pwck.

Is this a new systemd-only thinking, or is it something to be taken to the
shadow upstream (because {grp,pw}ck is provided by shadow)?

 
Does it mean that on each update, a package manager should touch
/etc/.updated?
   
   Hmm? No. A package manager should touch /usr after having done its work.
  
  Just to see if I understand: this would mean that ConditionNeedsUpdate = 
  .true.
  for /etc, no? So, we _do_ want systemd-sysusers.service, ldconfig.service, 
  et
  al. to run on next boot after an update?
 
 Well, the idea is that they are NOPs if they already ran from postinst...

OK. Fixing post_install scripts of every package is probably not going to
happen, so running the above services on-boot seems indeed better.

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


pgpyM02us48oK.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers and gshadow

[Lennart Poettering]

On Mon, 07.07.14 13:16, Leonid Isaev (lis...@umail.iu.edu) wrote:

 On Mon, Jul 07, 2014 at 05:40:42PM +0200, Lennart Poettering wrote:
  On Mon, 07.07.14 11:08, Leonid Isaev (lis...@umail.iu.edu) wrote:
  
   Hi,
   
 Thanks for the explanation...
   
   On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote:
I wasn#t aware of grpck, and quite frankly  don't think it makes much
sense, what the tool is doing.
   
   Why? Checking syntax can never hurt...
  
  Well, I am not opposed to that. I am just saying that otherwise the
  current logic so nicely considers an account with a missing counterpart
  in /etc/shadow disabled with no way to log in, which is exactly what we
  want here. However, grpck tool breaks that...
 
 Ah, right. So you mean grpck _and_ pwck.
 
 Is this a new systemd-only thinking, or is it something to be taken to the
 shadow upstream (because {grp,pw}ck is provided by shadow)?

Well, I do like the behaviour of things when an entry is missing. But
then again, I figure this is something to fix in systemd, and make
systemd create the entry in the shadow file, too.

Added to TODO list.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel