Re: [systemd-devel] Using LoadCredential for passing API key to s3 bucket mount unit

2021-09-02 Thread Vladimir Timofeenko
Hi Lennart,

Thank you for your reply!

> systemd only resolves env vars in ExecXYZ= lines, nowhere else. And
> definitely not in Options=

Background: fuse mounts can use arbitrary executables that provide
mount-like calling interface. Those executables can be specified as type
fuse.$my_executable.

For example, the following script can be placed in arbitrary place in
$PATH as "my_wrapper":


#!/bin/sh

env

echo "My credentials directory: ${CREDENTIALS_DIRECTORY}"
echo "Its contents:"
ls -als "${CREDENTIALS_DIRECTORY}"

echo "My argv: $@"

# failing noop, not mounting anything
# this could be a call to s3fs
false

Then, this mount unit could call it:

[Unit]
Description=tmp bucket mount
After=network.target

[Mount]
What=temp-bucket
Where=/mnt/tmp
Type=fuse.my_wrapper
LoadCredential=password_file:/etc/s3fs/tmp_key
Options=passwd_file="${CREDENTIALS_DIRECTORY}"/password_file


This results in the following in journald:


systemd[1]: Mounting tmp bucket mount...
mount[539027]: CREDENTIALS_DIRECTORY=/run/credentials/mnt-tmp.mount
mount[539027]: PWD=/
mount[539027]: SYSTEMD_EXEC_PID=539025
mount[539027]: _=/usr/bin/env
mount[539027]: HOME=/root
mount[539027]: LANG=en_US.utf8
mount[539027]: INVOCATION_ID=f5f58395a5f04f349c97d19a400bfedf
mount[539027]: SHLVL=1
mount[539027]: JOURNAL_STREAM=8:14978691
mount[539026]: My credentials directory: /run/credentials/mnt-tmp.mount
mount[539026]: Its contents:
mount[539028]: ls: cannot access '/run/credentials/mnt-tmp.mount': No such file 
or directory
mount[539026]: My argv: temp-bucket /mnt/tmp -o 
rw,passwd_file="/run/credentials/mnt-tmp.mount"/password_file,dev,suid
systemd[1]: mnt-tmp.mount: Mount process exited, code=exited, status=1/FAILURE
systemd[1]: mnt-tmp.mount: Failed with result 'exit-code'.
systemd[1]: Failed to mount tmp bucket mount.


Judging by "My argv" line, while the systemd itself would not
resolve CREDENTIALS_DIRECTORY, the mounting script ultimately
does receive its contents if it was specified in Options=

> $CREDENIALS_DIRECTORY should already point to a dir with the unit name
> in it. i.e. what is the precise value?

Apologies, I misspoke in my previous mail. The actual directory is _not_
created, see output above.

$CREDENIALS_DIRECTORY variable does get the expected value
"/run/credentials/mnt-tmp.mount", but this path is not created, thus the
credentials are not passed, see above.

> Consider filing an issue on github, if the creds stuff doesn't
> work. But note that the env var replacement you need to do in mout
> mount.fuse.s3fs wrapper script really, PID 1 won't do that for you.

Can you please confirm that my example wrapper above looks like it should work? 
If
so, I will file the issue.

--
With best regards,
--
Vladimir Timofeenko


Re: [systemd-devel] Using LoadCredential for passing API key to s3 bucket mount unit

2021-09-02 Thread Lennart Poettering
On Mi, 01.09.21 13:31, Vladimir Timofeenko (vladi...@vtimofeenko.com) wrote:

> Hi,
>
> I am playing with the idea of using systemd mount to mount S3 bucket on
> the system using s3fs.
>
> To mount a bucket, an API key is required. s3fs can read the API key
> from a file specified as an option:
>
> s3fs $bucket_name $where -o passwd_file=${PATH_TO_PASSWORD_FILE} ...
>
> I tried to set up a .mount unit with LoadCredential directive:
>
> [Unit]
> Description=tmp bucket mount
> After=network.target
>
> [Mount]
> What=temp-bucket
> Where=/mnt/tmp
> Type=fuse.s3fs
> LoadCredential=password_file:/etc/s3fs/tmp_key
> Options=passwd_file="${CREDENTIALS_DIRECTORY}"/password_file,url=https://s3...

systemd only resolves env vars in ExecXYZ= lines, nowhere else. And
definitely not in Options=

> I have used a small wrapper that calls env before calling s3fs to
> investigate, and it appears that during the mount command execution
> ${CREDENTIALS_DIRECTORY} is created, but there is no subdirectory
> corresponding to the unit name.

$CREDENIALS_DIRECTORY should already point to a dir with the unit name
in it. i.e. what is the precise value?

I must admit I never tested credentials with mount units. We might be
missing something there, though I see no reason why it shouldn't work.

Consider filing an issue on github, if the creds stuff doesn't
work. But note that the env var replacement you need to do in mout
mount.fuse.s3fs wrapper script really, PID 1 won't do that for you.

Lennart

--
Lennart Poettering, Berlin


[systemd-devel] Using LoadCredential for passing API key to s3 bucket mount unit

2021-09-01 Thread Vladimir Timofeenko
Hi,

I am playing with the idea of using systemd mount to mount S3 bucket on
the system using s3fs.

To mount a bucket, an API key is required. s3fs can read the API key
from a file specified as an option:

s3fs $bucket_name $where -o passwd_file=${PATH_TO_PASSWORD_FILE} ...

I tried to set up a .mount unit with LoadCredential directive:

[Unit]
Description=tmp bucket mount
After=network.target

[Mount]
What=temp-bucket
Where=/mnt/tmp
Type=fuse.s3fs
LoadCredential=password_file:/etc/s3fs/tmp_key
Options=passwd_file="${CREDENTIALS_DIRECTORY}"/password_file,url=https://s3...

[Install]
WantedBy=multi-user.target

However mount start fails with s3fs not being able to read from
passwd_file:

s3fs: specified passwd_file is not readable.


I have used a small wrapper that calls env before calling s3fs to
investigate, and it appears that during the mount command execution
${CREDENTIALS_DIRECTORY} is created, but there is no subdirectory
corresponding to the unit name.

Is this a correct use for LoadCredential?


systemctl --version
systemd 248 (248)
+PAM -AUDIT -SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS
+OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 +IDN2 -IDN -IPTC +KMOD
+LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE -BZIP2 +LZ4
-XZ -ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

OS: Gentoo

--
With best regards,
--
Vladimir Timofeenko