Project

General

Profile

Bug #20217

cephfs can be mounted even when keyring is modified

Added by xiaomeng tu about 4 years ago. Updated almost 4 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

Duplicated by Ceph - Bug #20189: fs Duplicate 06/05/2017

History

#1 Updated by xiaomeng tu about 4 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.

#2 Updated by Nathan Cutler about 4 years ago

#3 Updated by Greg Farnum almost 4 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!

Also available in: Atom PDF