Project

General

Profile

Actions

Bug #20217

closed

cephfs can be mounted even when keyring is modified

Added by xiaomeng tu almost 7 years ago. Updated almost 7 years ago.

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

0%

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

Description

Modified the last letter of keyring, cephfs can be mounted with this wrong keyring and write/read operation is also allowed.

For example the original keyring is:
AQD6wjRZQPEcORAAeXPNPkN36VEiwc7Y/OBZcw==

the modified keyring is:
AQD6wjRZQPEcORAAeXPNPkN36VEiwc7Y/OBZcx==

or
AQD6wjRZQPEcORAAeXPNPkN36VEiwc7Y/OBZcy==

A change pattern seems like change the "w" to "x" or "A" to "B", which always work.
Numbers of keyrings are tested and the problem remains.

How does ceph cluster verify the client's keyring, is it a 100% comparison?


Related issues 1 (0 open1 closed)

Has duplicate Ceph - Bug #20189: fsDuplicate06/05/2017

Actions
Actions #1

Updated by xiaomeng tu almost 7 years ago

It turns out to be a base64 decoding problem. In base64 algorithm,“AQD6wjRZQPEcORAAeXPNPkN36VEiwc7Y/OBZcw==” and "AQD6wjRZQPEcORAAeXPNPkN36VEiwc7Y/OBZcx==" can be decoded into the same hex characters, which means this two keyring both can help the client get through the authentication send from the server end.

Actions #2

Updated by Nathan Cutler almost 7 years ago

Actions #3

Updated by Greg Farnum almost 7 years ago

  • Status changed from New to Closed

Sounds like the last character just has so,e overflow that can be noise because it isn't read. Glad this isn't a security issue!

Actions

Also available in: Atom PDF