How can non-admin SWIFT users, administer Red Hat Gluster Storage containers?

Solution Unverified - Updated -

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 permissions
    • docs: readable by all

In this environment, the following users are present:

  • admin: full permissions
  • uploader: write permissions in the incoming container
  • downloader: read permissions in the incoming container
  • editor: write permissions in the doc 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:

  1. anyone should be able to read and list the contents in docs
  2. editor should be able to modify the contents in docs
  3. editor should not be able to read contents in incoming
  4. uploader should be able to upload objects to incoming
  5. downloader should be able to download only known objects from incoming

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 full curl 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:

  1. 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

  2. Allow the editor to write the contents of docs:

    $ curl -H POST -H "X-Container-Write: dropbox:editor" \
    http://localhost:8080/v1/AUTH_dropbox/docs

  3. Deny the editor to read anything from incoming:

    $ curl -H POST -H "X-Container-Read: .r:-editor" \
    http://localhost:8080/v1/AUTH_dropbox/incoming

  4. Allow the uploader to write to incoming:

    $ curl -H POST -H "X-Container-Write: dropbox:uploader" \
    http://localhost:8080/v1/AUTH_dropbox/incoming

  5. Allow downloader to read from incoming, 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