This bug was fixed in the package shadow - 1:4.5-1.1ubuntu4
---
shadow (1:4.5-1.1ubuntu4) eoan; urgency=medium
* debian/patches/1015_add_zsys_support.patch:
- Call zsys to handle home directory if available.
We call zsys to handle dataset creation for zsys system in a separa
This bug was fixed in the package zsys - 0.2
---
zsys (0.2) eoan; urgency=medium
* Add userdata hidden subcommand for creating and renaming user datasets.
(LP: #1842902)
* Build-dep on grub2-common to not produce s390x build for now until
we support an alternative bootload
Thanks a lot Łukasz! The MIR is available at
https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271, the MIR
part has been acked, it's pending a security review for now.
Anyway, let's proceed with this so that we can test it early in the
wild, thanks again!
--
You received this bug notifica
Thanks Didier and Alex! This looks promising. I'm generally +1 on this,
especially that the shadow part of the feature doesn't have to be
blocked on zsys - if all works correctly that is.
For the zsys part, I assume that once we have that we'd like to pull in
zsys to main. Did you reach out to the
attaching shadow build logs
** Attachment added: "shadow_4.5-1.1ubuntu4_amd64.build"
https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1842902/+attachment/5287475/+files/shadow_4.5-1.1ubuntu4_amd64.build
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Thanks Didier, looks great :)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1842902
Title:
FFe: create zfs dataset for each user automatically
Status in shadow package in
Hey Alex! Thanks for looking at it.
Sure, I've added some checks for open/dup2 (and exiting the child).
On execl, I've kept the similar logic than the rest of the code, meaning:
- don't check for execl return value.
- if something bad happen, execl returns.
- we go on the next line which is a per
Didier - could you please add some checks on the return values from the
various open/dup2/execvl syscalls? Whilst currently I can't see a huge
problem if these silently fail (open returns -1, dup2 then fails, or if
dup2 fails anyway - then the only consequence is stdout/stderr is not
silenced) I t
8 matches
Mail list logo