diff options
author | Csaba Henk <csaba@gluster.com> | 2011-09-11 19:45:57 +0200 |
---|---|---|
committer | Vijay Bellur <vijay@gluster.com> | 2011-09-22 05:23:32 -0700 |
commit | 2ab00369e7ef99d287dad5301d2f334dcfd67a70 (patch) | |
tree | c4e7c2ac9f3285f6d2617133b131d924044dc786 /xlators/lib | |
parent | 1098aaa51d2e3dca9e6c48ee1e9cb43bc87936f4 (diff) |
gsyncd: implement restricted mode and utility dispatch
With this change, the suggested way of setting up a geo-sync
slave is to use an ssh key with gsyncd as a forced command
(see sshd(8)), or set gsyncd as shell. This prevents the master
in executing arbitrary commands on slave (a major security hole).
Detailed list the changes:
- All gsyncd invocations that are not done by glusterd are
considered unsafe and then we operate in so-called "restricted mode"
(see below)
- if we are invoked on purpose (ie. it's not the case that sshd forced
us to run as frontend of a remote-invoked command), we execute gsyncd.py
- if invoked by sshd as frontend command, we check the remote command
line and call the required utility if it's among the allowed ones
(rsyncd and gsyncd)
- with rsync, we check if invocation is server mode and some other
sanity measures
- with gsyncd, in restricted mode we enforce the usage of the glusterd
provided config file, and in python, we enforce operation in
server mode and some other sanity checks
Impact on using geo-rep the old way: remote file slave now also
requires a running glusterd (to pick up config from).
Missing: we not implemented check of the rsync target path.
The issue of master being able to modify arbitrary locations
is planned to be mitigated by using geo-rep with an unprivileged
user.
Change-Id: I9b5825bfe282a9ca777429aadd554d78708f1638
BUG: 2825
Reviewed-on: http://review.gluster.com/460
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vijay@gluster.com>
Diffstat (limited to 'xlators/lib')
0 files changed, 0 insertions, 0 deletions