Bug 812498 - Insecure world accessible mounts on UFO (Swift-API) server
Insecure world accessible mounts on UFO (Swift-API) server
Status: CLOSED CURRENTRELEASE
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gluster-swift (Show other bugs)
2.0
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Luis Pabón
:
Depends On:
Blocks: 817967
  Show dependency treegraph
 
Reported: 2012-04-13 22:34 EDT by Etsuji Nakai
Modified: 2016-11-08 17:24 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-10 06:54:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Etsuji Nakai 2012-04-13 22:34:42 EDT
Description of problem:

I set up UFO(Swift-API) as in the official doc.
http://docs.redhat.com/docs/en-US/Red_Hat_Storage/2/html/User_Guide/chap-User_Guide-UFO.html

And I found that gluster volumes mounted on the UFO server (and its subdirectories) have world accessible permissions as below:

-----------
[root@swift01 ~]# ls -l /mnt/
total 4
drwxrwxrwx. 3 root root 4096 Apr 14 10:26 gluster-object
[root@swift01 ~]# ls -l /mnt/gluster-object/
total 16
drwxrwxrwx. 5 root root 8192 Apr 14 11:26 AUTH_vol01
[root@swift01 ~]# ls -l /mnt/gluster-object/AUTH_vol01/
total 32
drwxrwxrwx. 2 root root 8192 Apr 14 10:32 container01
drwxrwxrwx. 2 root root 8192 Apr 14 10:32 tmp
-----------

It's not good in terms of security.

Version-Release number of selected component (if applicable):

swift-plugin-1.0.-1.el6.noarch
swift-1.4.5-1.noarch
Comment 1 Saurabh 2012-04-20 05:26:48 EDT
Info from my setup, I am using RHS2.0 with 3.3.0qa35 installed and swift-plugin-1.4.8

[root@localhost ~]# cd /mnt/gluster-object/AUTH_test
[root@localhost AUTH_test]# ls
container2  container3  dir  tmp
[root@localhost AUTH_test]# cd container2
[root@localhost container2]# mkdir tmp
[root@localhost container2]# ls -ld tmp/
drwxr-xr-x. 2 root root 12 Apr 20 03:19 tmp/
[root@localhost container2]# cd ..
[root@localhost AUTH_test]# ls -l
total 40
drwxr-xr-x. 4 root root 8192 Apr 20 03:19 container2
drwxr-xr-x. 2 root root   28 Apr 12 04:52 container3
drwxr-xr-x. 2 root root   33 Apr 12 05:13 dir
drwxr-xr-x. 2 root root   12 Apr 17 01:38 tmp
[root@localhost AUTH_test]# cd ..
[root@localhost gluster-object]# ls -l
total 16
drwxrwxrwx. 7 root root  154 Apr 12 04:33 AUTH_test
drwxr-xr-x. 2 root root 4096 Apr  9 06:33 AUTH_test1
drwxr-xr-x. 2 root root 4096 Apr 19 03:18 AUTH_test2
[root@localhost gluster-object]#
Comment 2 Junaid 2012-04-20 09:04:27 EDT
Hi Etsuji Nakai,


Thanks for filing the bug. As seen from Saurabh's comment, /mnt/gluster-object directory is created with permission 0777 and /mnt/gluster-object/AUTH_test (in your case /mnt/gluster-object/AUTH_vol01) is created with permission 0777. There was a bug in the code which is fixed now and will be available in next release.

But, files and directories under /mnt/gluster-object/AUTH_XXX are not created with 0777 permission which can be seen in the above comment.

To debug the issue further, can you provide the info about the setup and how were the files created (I mean via REST api's or gluster mount point)?
Comment 3 Etsuji Nakai 2012-04-21 07:38:05 EDT
Hi,

In my environment, RPM's are as below:

[root@rhs20-01 ~]# rpm -qa | grep swift
swift-plugin-1.0.-1.el6.noarch
swift-1.4.5-1.noarch

[root@rhs20-01 ~]# rpm -qa | grep glusterfs
glusterfs-server-3.3.0qa30-1.el6.x86_64
glusterfs-geo-replication-3.3.0qa30-1.el6.x86_64
glusterfs-3.3.0qa30-1.el6.x86_64
glusterfs-fuse-3.3.0qa30-1.el6.x86_64
glusterfs-rdma-3.3.0qa30-1.el6.x86_64

The concrete steps how I set them up is at the bottom of this note.

And, I used REST API's to create a container. The following is the terminal logging of what I've done.

1. Receive an authentication token.

[root@rhs20-01 ~]# curl -v -H 'X-Storage-User: vol01:admin' -H 'X-Storage-Pass:pas4vol01admin' -k https://localhost:443/auth/v1.0
* About to connect() to localhost port 443 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
* 	subject: CN=Swift API,ST=Tokyo,C=JP
* 	start date: Apr 21 11:14:20 2012 GMT
* 	expire date: Mar 28 11:14:20 2112 GMT
* 	common name: Swift API
* 	issuer: CN=Swift API,ST=Tokyo,C=JP
> GET /auth/v1.0 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: localhost
> Accept: */*
> X-Storage-User: vol01:admin
> X-Storage-Pass:pas4vol01admin
> 
< HTTP/1.1 200 OK
< X-Storage-Url: https://127.0.0.1:443/v1/AUTH_vol01
< X-Storage-Token: AUTH_tkb7c04db8142d4a6d94abead4112a456b
< X-Auth-Token: AUTH_tkb7c04db8142d4a6d94abead4112a456b
< Content-Length: 0
< Date: Sat, 21 Apr 2012 11:19:20 GMT
< 
* Connection #0 to host localhost left intact
* Closing connection #0


2. Create "container01".

[root@rhs20-01 ~]# curl -v -X PUT -H 'X-Auth-Token: AUTH_tkb7c04db8142d4a6d94abead4112a456b' https://localhost:443/v1/AUTH_vol01/container01 -k
* About to connect() to localhost port 443 (#0)
*   Trying ::1... Connection refused
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
* 	subject: CN=Swift API,ST=Tokyo,C=JP
* 	start date: Apr 21 11:14:20 2012 GMT
* 	expire date: Mar 28 11:14:20 2112 GMT
* 	common name: Swift API
* 	issuer: CN=Swift API,ST=Tokyo,C=JP
> PUT /v1/AUTH_vol01/container01 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: localhost
> Accept: */*
> X-Auth-Token: AUTH_tkb7c04db8142d4a6d94abead4112a456b
> 
< HTTP/1.1 201 Created
< Content-Length: 18
< Content-Type: text/html; charset=UTF-8
< Date: Sat, 21 Apr 2012 11:19:37 GMT
< 
201 Created



* Connection #0 to host localhost left intact
* Closing connection #0


3. At this point, both /mnt/gluster-object/AUTH_vol01/ and **/mnt/gluster-object/AUTH_vol01/container01** have the permission 0777.

[root@rhs20-01 ~]# ls -l /mnt/gluster-object/
total 0
drwxrwxrwx. 4 root root 123 Apr 21 11:19 AUTH_vol01

[root@rhs20-01 ~]# ls -l /mnt/gluster-object/AUTH_vol01/
total 0
drwxrwxrwx. 2 root root 18 Apr 21 11:19 container01


4. As an additional test, I used "swift" command to upload an object. The permission of the uploaded file is correctly secured.

[root@rhs20-01 ~]# swift -A https://localhost/auth/v1.0 -U vol01:admin -K pas4vol01admin upload container01 file01.txt
file01.txt

[root@rhs20-01 ~]# ls -l /mnt/gluster-object/AUTH_vol01/container01/total 4
-rw-------. 1 root root 43 Apr 21 11:20 file01.txt


5. The installation steps are as below:

# yum install -y memcached openssl python-setuptools python-paste python-paste-deploy python-configobj python-simplejson python-configobj
# easy_install-2.6 coverage
# yum localinstall -y http://yum.griddynamics.net/yum/diablo/python-greenlet-0.3.1-4.x86_64.rpm \
 http://yum.griddynamics.net/yum/diablo/python-eventlet-0.9.16-gd1.el6.noarch.rpm \
 http://yum.griddynamics.net/yum/diablo/python-webob-1.0.8-0.noarch.rpm \
 http://kojipkgs.fedoraproject.org/packages/python-netifaces/0.5/1.el6/x86_64/python-netifaces-0.5-1.el6.x86_64.rpm \
 http://kojipkgs.fedoraproject.org/packages/pyxattr/0.5.0/1.el6/x86_64/pyxattr-0.5.0-1.el6.x86_64.rpm
# chkconfig memcached on
# service memcached start
# cd /etc/swift
# openssl req -new -x509 -nodes -out cert.crt -keyout cert.key -days 36500 -subj "/C=JP/ST=Tokyo/CN=Swift API"

And, edit /etc/swift/proxy-server.conf as below:

[root@rhs20-01 ~]# cat /etc/swift/proxy-server.conf 
[DEFAULT]
bind_port = 8080
user = root
log_facility = LOG_LOCAL1
bind_port = 443
cert_file = /etc/swift/cert.crt
key_file = /etc/swift/cert.key

[pipeline:main]
pipeline = healthcheck cache tempauth proxy-server

[app:proxy-server]
use = egg:swift#proxy
allow_account_management = true
account_autocreate = true

[filter:tempauth]
use = egg:swift#tempauth
#user_<account>_<user name> = <password> [.admin]
user_vol01_admin = pas4vol01admin .admin
user_vol01_user01 = pas4vol01user01
user_vol02_admin = pas4vol02adm .admin
user_vol02_user01 = pas4vol02user01

[filter:healthcheck]
use = egg:swift#healthcheck

[filter:cache]
use = egg:swift#memcache
memcache_servers = localhost:11211
Comment 4 Etsuji Nakai 2012-04-27 10:27:30 EDT
Hi, Junaid

I tried the latest rpms which you informed to me.

# rpm -qa | grep swift
gluster-swift-proxy-1.4.8-1.el6.noarch
gluster-swift-1.4.8-1.el6.noarch
gluster-swift-plugin-1.0-1.noarch
gluster-swift-account-1.4.8-1.el6.noarch
gluster-swift-object-1.4.8-1.el6.noarch
gluster-swift-container-1.4.8-1.el6.noarch

I could confirm that the problem was resolved with them. I repeated the same steps and the result was as below:

----
# ls -l /mnt/gluster-object/
total 0
drwxr-xr-x. 5 root root 102 Apr 27 14:22 AUTH_vol02

# ls -l /mnt/gluster-object/AUTH_vol02
total 0
drwxr-xr-x. 2 root root 27 Apr 27 14:22 container03
drwxr-xr-x. 2 root root 12 Apr 27 14:22 tmp

# ls -l /mnt/gluster-object/AUTH_vol02/container03/
total 4
-rw-------. 1 root root 43 Apr 27 14:22 file.txt
----

Thanks!
Comment 5 Etsuji Nakai 2012-04-27 10:41:46 EDT
One thing to note...

There's a mistake in the prereq of your gluster-swift-1.4.8-1.el6.noarch.

# rpm -q --requires gluster-swift-1.4.8-1.el6.noarch | grep webob
python-webob1.0

It requires "python-webob1.0". It should be  "python-webob-1.0", instead.

# rpm -qa | grep webob
python-webob-1.0.8-0.noarch

I had to use some --nodeps tricks to install your rpms because of this problem.
Comment 6 Junaid 2012-04-30 23:56:24 EDT
Hi Etsuji,

Thanks for the info. 

About python-webob1.0, it is being done intentionally and the python-webob1.0 
rpm will be available in the new RHS iso. For now you can find the rpm at 

http://shell.gluster.com/~junaid/swift-rpms/python-webob1.0-1.0.8-3.el6_rhs2.0.noarch.rpm

I will mark the bug as fixed and close it.

Thanks,
Junaid

Note You need to log in before you can comment on or make changes to this bug.