Project

General

Profile

Bug #676

inconsistent handling of g_conf.keyring

Added by Colin McCabe about 13 years ago. Updated about 13 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

In some places we treat g_conf.keyring as a single string. In others, we treat it as a comma-separated array. Sometimes we expand tildes in the path; other times we don't.

In my opinion, we should just handle g_conf.keyring like all other paths-- as a string. Making it a list seems confusing and unnecessary. If we are going to do shell expansion, we should use wordexp(2) rather than re-inventing the wheel.

However, since many of our programs run with root permissions, I am not convinced that doing shell expansion is a good idea. It can cause subtle security holes. Also, most of the interesting environment variables like $HOME should not be set when a daemon is running.

I found this while reworking the qa/rbd.sh script. I am unable to set the keyring automatically because I don't know whether it's a string or a comma-separated list. Parsing comma-separated lists in bash will be painful too if we decide to go with that interpretation.

History

#1 Updated by Sage Weil about 13 years ago

  • Target version set to v0.25

#2 Updated by Sage Weil about 13 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF