Implement a root_squash mode in MDS auth caps to deny operations for
clients with uid=0 or gid=0 that need write access. It's mainly to
prevent operations such as accidental `sudo rm -rf /path`.
The root squash mode can be enforced in one of the following ways in
the MDS caps,
'allow rw root_squash'
(across file systems)
or
'allow rw fsname=a root_squash'
(on a file system)
or
'allow rw fsname=a path=/vol/group/subvol00 root_squash'
(on a file system path)
Fixes: https://tracker.ceph.com/issues/42451
Signed-off-by: Ramana Raja <rraja@redhat.com>
Add new auth caps to restrict access to clients based on fsnames. To
specify this, for example:
mds 'allow rw fsname=cephfs1'
This will restrict client access to fs name "cephfs1" only. Messages to
active MDS assigned to any other FSMap will be dropped. Standby MDS not
associated with an FSMap will accept messages from clients. To allow
multiple file systems, create MDS cap as follows -
mds 'allow rw fsname=cephfs1, allow rw fsname=cephfs2'
Fixes: http://tracker.ceph.com/issues/15070
Signed-off-by: Douglas Fuller <dfuller@redhat.com>
Signed-off-by: Rishabh Dave <ridave@redhat.com>
Add a 'fsname' clause to mon auth caps to restrict a client's view
of the FSMap. Example:
mon 'allow rw fsname=cephfs2'
This would restrict the client's view of the FSMap to the MDSMap for
cephfs2. Any MDS allocated to a different filesystem will be invisible.
Global standby daemons are always visible. To allow multiple CephFSs,
add multiple caps:
mon 'allow rw fsname=cephfs2, allow rw fsname=cephfs2'
Fixes: http://tracker.ceph.com/issues/15070
Signed-off-by: Douglas Fuller <dfuller@redhat.com>
Signed-off-by: Rishabh Dave <ridave@redhat.com>
According to the path restriction example, the filesystem name
should be cephfs_a, not cephfs. Converge on cephfs_a to avoid it
being confused with with the pool tag, which is always cephfs.
This was introduced in 160c4bfeb8 ("mon/AuthMonitor: Use new osd
auth caps for ceph fs authorize").
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
For controlling whether a client is allowed to create or delete
snapshots
Fixes: http://tracker.ceph.com/issues/24284
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Define the string 'all' to be a synonym for the wildcard '*'. This
avoids confusion in the event that some auth caps (typically with
ceph fs authorize) are not quoted and thus '*' is expanded by the shell.
Signed-off-by: Douglas Fuller <dfuller@redhat.com>
Change 'ceph fs authorize' to grant osd auth caps by pool tag
instead of to current data pools. This makes:
ceph fs authorize cephfs_a client.foo /bar rw
now equivalent to:
ceph auth get-or-create client.foo mon 'allow r' mds 'allow rw path=/bar' osd 'allow rw tag cephfs data=cephfs_a'
Signed-off-by: Douglas Fuller <dfuller@redhat.com>
As described in http://tracker.ceph.com/issues/17937, a client with
restricted pool access can still delete files unless a corresponding
MDS path restriction is also in place.
Signed-off-by: David Disseldorp <ddiss@suse.de>
When user is mounted a quota-restricted inode
as the root, report that inode's quota status
as the filesystem statistics in statfs.
This allows us to have a fairly convincing illusion
that someone has a filesystem to themselves, when
they're really mounting a restricted part of
the larger global filesystem.
Fixes: http://tracker.ceph.com/issues/15599
Signed-off-by: John Spray <john.spray@redhat.com>
