Project

General

Profile

Bug #10844

mon: caps validation should rely on EntityName instead of entity_name_t

Added by Joao Luis almost 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
Monitor
Target version:
-
Start date:
02/11/2015
Due date:
% Done:

0%

Source:
other
Tags:
Backport:
firefly, giant
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:

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 almost 4 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 over 3 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 over 3 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 Luis almost 4 years ago

  • Status changed from New to Need Review

#2 Updated by Sage Weil almost 4 years ago

  • Status changed from Need Review to Pending Backport

#5 Updated by Loic Dachary over 3 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 Loic Dachary over 3 years ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF