confined role account #1

Supports: xenial trusty
Add to new model


This charm lets members of certain groups sudo
to a role account confined by an apparmor profile.

Confined Role Account

This subordinate charm can be used to grant members of a given group read-only
access (with optional restrictions on other files as needed) to a specific role
account on an instance.

Let's take a look at how you'd deploy our confined-role-account subordinate
charm in practice. In our example, we're going to deploy MediaWiki and MySQL,
manually add an unprivileged user account on the MediaWiki server, and then
configure the confined-role-account subordinate charm so that our unprivileged
user can sudo to the www-data user, but with restricted access.

First of all, configure your juju environment and fire up the bootstrap

Then, deploy your charms into the environment:

juju deploy cs:charms/trusty/mediawiki
juju deploy cs:charms/trusty/mysql
juju add-relation mysql mediawiki:db

Now let's manually create our unprivileged user. In a production environment
we'd likely have a different means of doing this, such as via ldap.

juju ssh mediawiki/0
$ sudo adduser service-user

Now we can confirm that we can login as the account in question and see what
sudo permissions it has by default:

juju ssh mediawiki/0
$ sudo su - service-user
$ sudo -l
Sorry, user service-user may not run sudo on juju-env-machine-1.

Now we can deploy the confined-role-account subordinate charm, set our config
options for it, and add a relation to the mediawiki charm:

juju deploy cs:~confined-role-account-charmers/confined-role-account
juju set confined-role-account group=service-user role-account=www-data extra-apparmor-rules="  audit deny /etc/mediawiki/AdminSettings.php r,"
juju add-relation mediawiki confined-role-account

What is this doing? It's saying that anyone in the service-user group can sudo
to the www-data role account with the default read-only permissions, but also
with /etc/mediawiki/AdminSettings.php not visible to them. This file contains
the database password, and in our scenario we want to allow developers access
to the mediawiki server as the www-data role account without giving them access
to the production database password.

And now let's confirm how things look:

juju ssh mediawiki/0
$ sudo su - service-user
$ sudo -l
Matching Defaults entries for service-user on juju-canonistack-machine-1:
    env_reset, mail_badpass,

User service-user may run the following commands on juju-canonistack-machine-1:
    (www-data) NOPASSWD: /usr/local/sbin/apparmor-wrapper-service-user-www-data \"\"
$ sudo -u www-data /usr/local/sbin/apparmor-wrapper-service-user-www-data
$ echo "this is a test" > ~/this-is-a-test.txt
bash: /var/www/this-is-a-test.txt: Permission denied
$ head /etc/mediawiki/LocalSettings.php
$path = array( $IP, "$IP/includes", "$IP/languages" );
set_include_path( implode( PATH_SEPARATOR, $path ) . PATH_SEPARATOR .
get_include_path() );

require_once( "$IP/includes/DefaultSettings.php" );

# If PHP's memory limit is very low, some operations may fail.
# ini_set( 'memory_limit', '20M' );

if ( $wgCommandLineMode ) {
$ head /etc/mediawiki/AdminSettings.php
head: cannot open '/etc/mediawiki/AdminSettings.php' for reading: Permission denied

We can also see our command history in /var/log/apparmor-wrapper/www-data-history.log:

echo "this is a test" > ~/this-is-a-test.txt
head /etc/mediawiki/LocalSettings.php
head /etc/mediawiki/AdminSettings.php


(string) Extra rules to add to the generated profile.
(string) The group that can transition to the role account.
(string) The role account that members of GROUP can transition to.