Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 405277 - sys-cluster/maui-3.3.1-r2 build time secret key configuration
Summary: sys-cluster/maui-3.3.1-r2 build time secret key configuration
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Cluster Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-22 15:03 UTC by Volkmar Glauche
Modified: 2012-05-05 21:15 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Volkmar Glauche 2012-02-22 15:03:15 UTC
sys-cluster/maui uses a secret key defined at compile time to encrypt communication between server and client programs. Looking at the ebuild, there seems to be provision for a MAUI_KEY variable in make.conf when it is compiled for slurm.
When using torque as a resource manager, there seems to be no way to set this key explicitly before emerge. This results in different secret keys being used each time maui is emerged (e.g. on different nodes in a cluster). As a consequence, client binaries built on one host can not communicate to server binaries on another host.
If present, the ebuild should honour a MAUI_KEY variable also when compiled for torque.

Reproducible: Always
Comment 1 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2012-02-22 17:39:04 UTC
(In reply to comment #0)
> sys-cluster/maui uses a secret key defined at compile time to encrypt
> communication between server and client programs. Looking at the ebuild, there
> seems to be provision for a MAUI_KEY variable in make.conf when it is compiled
> for slurm.
> When using torque as a resource manager, there seems to be no way to set this
> key explicitly before emerge. This results in different secret keys being used
> each time maui is emerged (e.g. on different nodes in a cluster). As a
> consequence, client binaries built on one host can not communicate to server
> binaries on another host.
> If present, the ebuild should honour a MAUI_KEY variable also when compiled for
> torque.

I don't know why it was added in the first place. You don't want something secret to be in a publicly accessible file. The preferred mechanism for injecting key is using EXTRA_ECONF="--with-key=1234" emerge maui.
@alexxy ^^ ?

Out of curiosity why do you install maui on slave nodes?
Comment 2 Volkmar Glauche 2012-02-22 19:43:11 UTC
(In reply to comment #1)

Indeed, using EXTRA_ECONF to pass the secret key is a better way of keeping it secret.
The reason to install maui on some of the cluster nodes is that I want to have the diagnostic and status commands available on e.g. submit hosts. 
Best, Volkmar
Comment 3 Volkmar Glauche 2012-02-23 13:38:49 UTC
(In reply to comment #2)

Replying to myself:
EXTRA_ECONF must be set for each emerge of maui (e.g. re-emerge or update as well). Thus, the key needs to be stored somewhere.
Portage has support of per-package environment variables:

/etc/portage/package.env
/etc/portage/env/

It would be nice if the maui ebuild or doc could suggest to 
1) echo "sys-cluster/maui maui_key.conf" >> /etc/portage/package.env
2) mkdir /etc/portage/env
3) echo EXTRA_ECONF="--with-key=YOURKEY" >> /etc/portage/env/maui_key.conf

This way, a common key can be set without cluttering /etc/make.conf. Obviously, security considerations apply to /etc/portage/env now.

Best,
Volkmar