[systemd-devel] Systemd ask-password unable to handle cryptsetup passwords with \0 character inside ?

[Raphaël Gertz]

Hi,

My question is relative to the file 
systemd/src/shared/ask-password-api.c+651 :

l = strv_parse_nulstr(passphrase+1, n-1);

On documentation 
https://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/ it is 
specified that message should follow this pattern :

+passwordhere\0
or
-\0
With trailing \0 optional in both case.

If I am right it seems all password sent through AF_UNIX/SOCK_DGRAM are 
split using \0 character and cached as differents passwords.


I am trying to create a cgi which send password or keyfile through this 
system.


Cryptsetup can accept two case of password, a 512 max length passphrase 
in interactive mode or a 8192 * 1024 keyfile.

(I have read the source code to find that)

There seems to have nothing disallowing to have a password like "toto\0" 
or a keyfile containing "toto\0".


How am I supposed to submit password with \0 character inside or even 
worse case with a \0 at end ?


Same question with file ?

Should I try to go around ask-password service and run cryptsetup 
luksOpen behind his back and later shoot the ask-password process ?


Would it need an option to have password provided without modification 
with trailing \0 with a new format like :

=toto\0

With all content considered as a single password ?

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

Re: [systemd-devel] rkt container engine fetch user/perm patterns

[Lennart Poettering]

On Tue, 31.05.16 16:05, Brandon Philips (bran...@ifup.co) wrote:

> Hello Everyone-
> 
> The rkt container engine wants to run with different permissions pre-start
> and start. In pre-start it needs to fetch/download the container image
> which is an unprivileged operation. In start it needs admin level
> permissions to start the container stage1 (e.g. systemd-nspawn) and mount
> the root overlayfs.
> 
> One way of accomplishing this is:
> 
> ExecStartPre=/usr/bin/su rktfetchuser -c /usr/bin/rkt fetch
> quay.io/coreos/etcd blah blah
> ExecStart=/usr/bin/rkt run $(COREOS_VERSIONS_ETCD_FULL) blah blah
> 
> The other way would be to create a fetch service and a run service but that
> is sort of clunky for users to configure.
> 
> Are there other mechanisms to not require the use of wrappers like su?

The inverse exists with PermissionsStartOnly= already, and I am open
to extending this, but I am not entirely sure how. Do you have a
suggestion how that could look like in syntax?

That said, you can of course achieve the right thing by having a
second service that does the fetching of Type=oneshot and then add a
Requires= dep from the main service to it.

BTW: you really should "runuser" instead of "su" here I think. Both
are available in util-linux.

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] rkt container engine fetch user/perm patterns

[David Timothy Strauss]

There could be a (potentially socket-activated) service that handles
requests for image downloads.

On Tue, May 31, 2016, 11:06 Brandon Philips  wrote:

> Hello Everyone-
>
> The rkt container engine wants to run with different permissions pre-start
> and start. In pre-start it needs to fetch/download the container image
> which is an unprivileged operation. In start it needs admin level
> permissions to start the container stage1 (e.g. systemd-nspawn) and mount
> the root overlayfs.
>
> One way of accomplishing this is:
>
> ExecStartPre=/usr/bin/su rktfetchuser -c /usr/bin/rkt fetch
> quay.io/coreos/etcd blah blah
> ExecStart=/usr/bin/rkt run $(COREOS_VERSIONS_ETCD_FULL) blah blah
>
> The other way would be to create a fetch service and a run service but
> that is sort of clunky for users to configure.
>
> Are there other mechanisms to not require the use of wrappers like su?
>
> Thank You,
>
> Brandon
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] rkt container engine fetch user/perm patterns

[Brandon Philips]

Hello Everyone-

The rkt container engine wants to run with different permissions pre-start
and start. In pre-start it needs to fetch/download the container image
which is an unprivileged operation. In start it needs admin level
permissions to start the container stage1 (e.g. systemd-nspawn) and mount
the root overlayfs.

One way of accomplishing this is:

ExecStartPre=/usr/bin/su rktfetchuser -c /usr/bin/rkt fetch
quay.io/coreos/etcd blah blah
ExecStart=/usr/bin/rkt run $(COREOS_VERSIONS_ETCD_FULL) blah blah

The other way would be to create a fetch service and a run service but that
is sort of clunky for users to configure.

Are there other mechanisms to not require the use of wrappers like su?

Thank You,

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

Re: [systemd-devel] why does bootctl default to /boot and not to /boot/efi?

[Barry Scott]

On Monday 30 May 2016 18:47:22 Lennart Poettering wrote:
> On Sun, 29.05.16 19:39, Barry Scott (ba...@barrys-emacs.org) wrote:
> > I just came across the bootctl command. Atleast on Fedora 23 and 24
> > it errors out because /boot is not FAT EFI. I thought that if you are EFI
> > then the EFI was always in /boot/efi.
> 
> /boot and the ESP exist for the same reasons really, and do the same
> job. Hence, systemd by default mounts the ESP to /boot and installs
> sd-boot there.
> 
> /boot/efi is a really crazy idea, as this means you always have to
> mount /boot (and actually have it!) before you can mount the ESP, and
> that's just off. After all in sd-boot the kernels are simply placed in
> the ESP, and there's really no point in having /boot at all...
> 
> Some distros patch sd-boot/bootctl to use /boot/efi instead, and the
> other's don't but don't mount the ESP to /boot either.  Given that it
> is that way, it might make sense to revisit the idea of making /boot
> and the ESP the same thing. But I am pretty sure /boot/efi is really
> the worst idea, hence an acceptable alternatively might be to
> introduce /efi and mount the esp there, and simply not have /boot on
> legacy free systems.

Thank you for the background.

Barry

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