How can non-admin SWIFT users, administer Red Hat Gluster Storage containers?
Environment
- Red Hat Storage 2.1
- Red Hat Gluster Storage 3.1
- Accessing contents through Swift Object Store API
Supportability of tempauth
in Production Environments
tempauth
is a temporary authentication mechanism that will be replaced in future by a more scalable and enterprise ready solution. The usage of tempauth
is not suitable for production environments. Instead of tempauth
, production environments should defer the authentication to the application that utilizes the Swift Object Storage.
Issue
Standard cURL based operations that work for admin users defined through TempAuth
in /etc/swift/proxy-server.conf
are not possible for non-admin users.
Resolution
Red Hat Storage 2.1 :
An environment for this example:
- account (Red Hat Storage Volume):
dropbox
- containers (directories on the volume):
incoming
: very restricted permissionsdocs
: readable by all
In this environment, the following users are present:
admin
: full permissionsuploader
: write permissions in theincoming
containerdownloader
: read permissions in theincoming
containereditor
: write permissions in thedoc
container
This is configured in /etc/swift/proxy-server.conf
:
[filter:tempauth]
use = egg:swift#tempauth
# all passwords have been set to 'secret'
user_dropbox_admin = secret .admin
user_dropbox_uploader = secret
user_dropbox_downloader = secret
user_dropbox_editor = secret
A description of the ACLs that should get applied:
- anyone should be able to read and list the contents in
docs
editor
should be able to modify the contents indocs
editor
should not be able to read contents inincoming
uploader
should be able to upload objects toincoming
downloader
should be able to download only known objects fromincoming
Note:
In the examples below, the
X-Auth-Token
headers and similar have been removed. This makes the commands are a little more readable. For more information on how the fullcurl
commands look like, see My first Unified File Object (UFO) storage deployment.
Create the layout as admin
:
$ curl -H PUT http://localhost:8080/v1/AUTH_dropbox/incoming
$ curl -H PUT http://localhost:8080/v1/AUTH_dropbox/docs
As the admin
, the following ACLs should be set, see the numbering above:
-
Allow everyone to read and list the contents of
docs
:$ curl -H POST -H "X-Container-Read: .rlistings:.r:*" \ http://localhost:8080/v1/AUTH_dropbox/docs
-
Allow the
editor
to write the contents ofdocs
:$ curl -H POST -H "X-Container-Write: dropbox:editor" \ http://localhost:8080/v1/AUTH_dropbox/docs
-
Deny the
editor
to read anything fromincoming
:$ curl -H POST -H "X-Container-Read: .r:-editor" \ http://localhost:8080/v1/AUTH_dropbox/incoming
-
Allow the
uploader
to write toincoming
:$ curl -H POST -H "X-Container-Write: dropbox:uploader" \ http://localhost:8080/v1/AUTH_dropbox/incoming
-
Allow
downloader
to read fromincoming
, this needs to get merged with 3.:$ curl -H POST -H "X-Container-Read: .r:-editor,.r:downloader" \ http://localhost:8080/v1/AUTH_dropbox/incoming
The .rlistings
option in the ACL will be applied to all unprivileged users. It is not possible to limit the ability to list contents to certain users. Admin and Reseller users have full control, similar to 'root' on a normal filesystem.
Red Hat Gluster Storage 3.1 :
- Its a known issue in RHGS 3.1 to configure ACLs for user in accounts swift and reported in BZ#1304442
Root Cause
The documentation for Access Control Lists is relatively sparse. There are not many (functioning) examples that show the usage of ACLs. The main documentation for ACLs seems to be as follows. Please note, these documents are external to Red Hat and as such, we cannot validate the contents:
Diagnostic Steps
The ACLs for the container are saved in the extended attributes of the directory. These extended attributes are in a format that is written by Python (a format called pickle
). The script below can be used to display the extended attributes set by the Swift implementation:
swift-read-metadata.py
:
#!/usr/bin/python
#
# Use this script to display the metadata that Swift saved in the extended
# attributes of a file or directory.
#
# This script is supplied for rudimentary testing only. It is not full
# featured, and only does what it needs to do.
#
import sys
# TODO: replace popen by a Pythony xattr call
from os import popen
import pickle
filename = sys.argv[1]
# get the contents of the SWIFT metadata xattr
getfattr = popen('getfattr --only-values -n user.swift.metadata %s 2>/dev/null' % filename)
xattr = getfattr.read()
getfattr.close()
for (k, v) in pickle.loads(xattr).items():
# v is tuple, and its last item is 0
values = list()
for value in v[:-1]:
values.append(str(value))
print('%s: %s' % (k, ', '.join(values)))
This script can be used like this (on a storage server that has volume/account mounted):
$ ./swift-read-metadata.py /mnt/gluster-object/dropbox/incoming
X-Container-Write: dropbox:uploader
X-Bytes-Used: 0
X-Timestamp: 1382544079.83043
X-Container-Read: .r:-editor
X-Object-Count: 1
X-Type: container
X-PUT-Timestamp: 1382544079.83800
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments