All of lore.kernel.org
 help / color / mirror / Atom feed
* logfile created with root:root ownership when "log_file" config option specified
@ 2016-02-03 23:17 Karol Mroz
  2016-02-06  0:46 ` Karol Mroz
  0 siblings, 1 reply; 4+ messages in thread
From: Karol Mroz @ 2016-02-03 23:17 UTC (permalink / raw)
  To: ceph-devel

[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]

Greetings Ceph Developers,

I recently discovered that when explicitly setting "log_file" for radosgw in
ceph.conf, the logfile was created with root:root ownership. Initially I thought
that this was a RGW issue, which prompted me to open: http://tracker.ceph.com/issues/14613

Tracing this a bit further, I believe it to be a more general problem with when the
LogObs observer is invoked.

The LogObs observer is first invoked from global_pre_init() by way of:

global_pre_init():
...
  conf->apply_changes(NULL)
...

Which then invokes:

md_config_t::_apply_changes()
{
...
  // Make any pending observer callbacks
  for (rev_obs_map_t::const_iterator r = robs.begin(); r != robs.end(); ++r) {
    md_config_obs_t *obs = r->first;
    obs->handle_conf_change(this, r->second);
  }
...
}

Which in turn fires the LogObs observer code:

class LogObs : public md_config_obs_t {
...
void handle_conf_change()
...
  if (changed.count("log_file")) {
    log->set_log_file(conf->log_file);
    log->reopen_log_file();
  }
...

When "log_file" is specified in ceph.conf, Log::reopen_log_file() is called and
the logfile is open()'d. However, at this point in time, the daemon is still running
as root, and thus the logfile is created with root:root ownership.

A quick workaround is to manually not set "log_file" in ceph.conf. The default
logfile is then created later on in global_init(), by way of:

global_init()
...
  g_conf->call_all_observers();
...

This is called _after_ the correct permissions have been set.

From a quick glance, removing changed.count("log_file"...) from
LogObs::handle_conf_changes() would skip over the early logfile creation in this observer.
A more invasive option would be to remove conf->apply_changes() from global_pre_init(),
thus delaying running the observers for the first time until after the permissions drop.
However, I suspect there may be valid reason why conf->apply_changes() is needed in
global_pre_init()? As I'm not familiar with the nuances here, a comment from someone more
familiar with this would be appreciated.

-- 
Regards,
Karol

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-02-06  2:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-03 23:17 logfile created with root:root ownership when "log_file" config option specified Karol Mroz
2016-02-06  0:46 ` Karol Mroz
2016-02-06  2:02   ` Sage Weil
2016-02-06  2:09     ` Karol Mroz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.