We get the device list from ceph-volume lvm list, and decode the json
output, which at that point is tainted (perlsec (1)).
Untaint it here before calling, because it is currently the only
call-site using the information in a problematic way (run_command).
(the only other call-site being in pve5to6)
Alternatively we could untaint while reading the information, but then
should only return a small subset of the ceph-volume output.
The issue is most likely due to
cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in pve-common ('run_command:
improve performance for logging and long lines'),
Tested on a virtual testsetup by creating OSDs with second DB disk,
and destroying it via GUI (did not manage to get the error without the
DB disk)
Reported via our community forum:
https://forum.proxmox.com/threads/insecure-dependency-in-exec-during-osd-destroy.79574/
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
by deleteing it from $ceph_param we deleted it also from
$param since it was only a reference
fix it by extracting it beforehand
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
extracting the logic from the previous checkbox listener into a function, which
is also called on field changes and once in afterrender. Calling it initially
makes sure the hint is also displayed at the beginning when editing a storage
with no retention options configured, and the initial disabling of the input
fields for the isCreate case now also happens through that call.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
adapted from PBS. Main differences are:
* API has GET/DELETE distinction instead of 'dry-run'
* API expects a single property string for the prune options
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
... as this is now allowed by the API (createSchema() in PVE::SectionConfig).
It is only allowed by the update API call (updateSchema()).
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
Normally it's better to configure pruning (backup retention) on the
backup server only, as then multiple client settings may not
interfere with each other due to outdated or to strict prune
settings (remember, the strictest prune setting always wins).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Support all prune keep- settings we have.
masked if the storage cannot support backups.
We do not care if it is disabled as content type for now, a user can
just set them nonetheless (could show a hint though).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If keep-all is set to 0, adding it doesn't make a difference,
if the key is not in the hash, it won't show up in the 'values'.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Hi to the people from the future which came here due to git blame or
the like. `git show -w` should proof that you got the wrong one.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Commit 2dcc87c798 removed the statefulness from
the other storage content views, so remove it from the remaining ones too.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Try to find out the newest version in the cluster and select that (if
in the known OK list).
Slightly hacky, but nothing really out of the ordinary, so should be
OK.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we sometimes need to adapt parameters, but in a lot contexts the
component is already created, and the activate event order of
components may make this hard to do in a deterministic way.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If the command itself allows it, which normally means it has good
verification of passed arguments.
We may want to re-evaluate security here if we allow execution for a
group of non-root users.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
