Project

General

Profile

Bug #10844

mon: caps validation should rely on EntityName instead of entity_name_t

Added by Joao Eduardo Luis about 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Joao Eduardo Luis
Category:
Monitor
Target version:
-
% Done:

0%

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

Description

More precisely, on MonCapGrand::expand_profile(), we take an entity_name_t to properly fill in config-key's grants on profile osd.

If we happen to need to get/set a config-key for a given osd using a client (e.g., ceph --name osd.X config-key exists daemon-private/osd.X/foo), we'll get an EACCES -- that's because the monitor is using the client's msgr entity (e.g., client.12345) as the entity when expanding the caps profile, instead of osd.X.

Associated revisions

Revision 87544f68 (diff)
Added by Joao Eduardo Luis about 9 years ago

mon: MonCap: take EntityName instead when expanding profiles

entity_name_t is tightly coupled to the messenger, while EntityName is
tied to auth. When expanding profiles we want to tie the profile
expansion to the entity that was authenticated. Otherwise we may incur
in weird behavior such as having caps validation failing because a given
client messenger inst does not match the auth entity it used.

e.g., running

ceph --name osd.0 config-key exists foo daemon-private/osd.X/foo

has entity_name_t 'client.12345' and EntityName 'osd.0'. Using
entity_name_t during profile expansion would not allow the client access
to daemon-private/osd.X/foo (client.12345 != osd.X).

Fixes: #10844
Backport: firefly,giant

Signed-off-by: Joao Eduardo Luis <>

Revision 8ef14fcc (diff)
Added by Joao Eduardo Luis about 9 years ago

mon: MonCap: take EntityName instead when expanding profiles

entity_name_t is tightly coupled to the messenger, while EntityName is
tied to auth. When expanding profiles we want to tie the profile
expansion to the entity that was authenticated. Otherwise we may incur
in weird behavior such as having caps validation failing because a given
client messenger inst does not match the auth entity it used.

e.g., running

ceph --name osd.0 config-key exists foo daemon-private/osd.X/foo

has entity_name_t 'client.12345' and EntityName 'osd.0'. Using
entity_name_t during profile expansion would not allow the client access
to daemon-private/osd.X/foo (client.12345 != osd.X).

Fixes: #10844
Backport: firefly,giant

Signed-off-by: Joao Eduardo Luis <>
(cherry picked from commit 87544f68b88fb3dd17c519de3119a9ad9ab21dfb)

Revision 4427358b (diff)
Added by Joao Eduardo Luis about 9 years ago

mon: MonCap: take EntityName instead when expanding profiles

entity_name_t is tightly coupled to the messenger, while EntityName is
tied to auth. When expanding profiles we want to tie the profile
expansion to the entity that was authenticated. Otherwise we may incur
in weird behavior such as having caps validation failing because a given
client messenger inst does not match the auth entity it used.

e.g., running

ceph --name osd.0 config-key exists foo daemon-private/osd.X/foo

has entity_name_t 'client.12345' and EntityName 'osd.0'. Using
entity_name_t during profile expansion would not allow the client access
to daemon-private/osd.X/foo (client.12345 != osd.X).

Fixes: #10844
Backport: firefly,giant

Signed-off-by: Joao Eduardo Luis <>
(cherry picked from commit 87544f68b88fb3dd17c519de3119a9ad9ab21dfb)

History

#1 Updated by Joao Eduardo Luis about 9 years ago

  • Status changed from New to Fix Under Review

#2 Updated by Sage Weil about 9 years ago

  • Status changed from Fix Under Review to Pending Backport

#5 Updated by Loïc Dachary about 9 years ago

4427358 mon: MonCap: take EntityName instead when expanding profiles (in giant), 8ef14fc mon: MonCap: take EntityName instead when expanding profiles (in firefly),

#6 Updated by Loïc Dachary about 9 years ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF