[slurm-users] Kernel keyrings on Slurm node inside Slurm job
Yair Yarom
irush at cs.huji.ac.il
Wed Aug 24 08:43:53 UTC 2022
Hi,
I think you should look at pam_keyinit and add it to the slurm pam (the one
used with the UsePAM configuration).
We currently don't do this, but it's on the todo list to check it out...
(so I'm not sure if it will work, or if it's the right way to do this).
On Tue, 23 Aug 2022 at 16:36, Matthias Leopold <
matthias.leopold at meduniwien.ac.at> wrote:
> Hi,
>
> I want to access the kernel "user" keyrings inside a Slurm job on a
> Ubuntu 20.04 node. I'm not an expert on keyrings (yet), I just
> discovered that inside a Slurm job a keyring for "user: invocation_id"
> is used, which seems to be shared across all users of the executing
> Slurm node (other users can access/destroy my keys).
>
> The structure in a session run from Slurm looks like this (when using
> cifscreds):
>
> Session Keyring
>
> 989278347 --alswrv 0 0 keyring: _ses
>
> 446567140 ----s-rv 0 0 \_ user: invocation_id
>
> 638050420 ----sw-v 35816 10513 \_ logon: cifs:d:itsc-test2
>
>
> The structure in a SSH session looks like this (when using cifscreds):
>
> Session Keyring
>
> 932177825 --alswrv 1000 1000 keyring: _ses
>
> 826996940 --alswrv 1000 65534 \_ keyring: _uid.1000
>
> 1006610690 ----sw-v 1000 1000 \_ logon: cifs:d:itsc-test2
>
>
> I researched about this invocation_id and found a section on
> "KeyringMode=" in systemd.exec man page, but that didn't really help me.
>
> Can you explain to me how it would be possible to get "private" keyrings
> inside a Slurm job on the executing node?
>
> thx
> Matthias
>
>
--
/| |
\/ | Yair Yarom | System Group (DevOps)
[] | The Rachel and Selim Benin School
[] /\ | of Computer Science and Engineering
[]//\\/ | The Hebrew University of Jerusalem
[// \\ | T +972-2-5494522 | F +972-2-5494522
// \ | irush at cs.huji.ac.il
// |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20220824/25bf93e3/attachment.htm>
More information about the slurm-users
mailing list