So I have been kicking around an idea for a while now and thought I would
develop it but its out of my league. The FreeIPA community is very very
active in pam/sssd/ldap/so on and so on so I thought I would float the idea
here before I made a Trac [RFE] ticket.

Advertising

**
Would anyone else find it useful to store environment variables in LDAP?
In the environment (no pun intended) I work in we have a few thousand
servers all authenticating to LDAP and a home grown LDAP+sshPublicKey
implementation which is great. But we have a bunch of different distros
which all have different default editors. Unless I feel like touching a
lot of servers or using cfengine3 to distribute my preferred environment
variables I am at the mercy of the editor on the system.
How wonderful would it be to set EDITOR=vim, LESS='-S',
TZ='America/Hawaii', LANG='Klingon' in LDAP and have pam/sss pull/store
that information for me. Sort of like pam_env but backed by LDAP.
So this got me thinking the other thing that would be wonderful to store in
LDAP would be shell profiles... Consider having your ~/.profile or
~/.bashrc or ~/.my.cnf or what-have-you in LDAP?
Maybe this modified pam_ldap could do things like append, remove, replace
or unset environment variables. Consider:
dn: uid=me,dc=example,dc=com
objectClass: posixAccountEnv
...
# replace EDITOR
posixEnv: EDITOR=vim
# unset TZ
posixEnv: TZ-=
# append PATH
posixEnv: PATH=+:~/bin
# prepend PATH
posixEnv: PATH+=/opt/foo/bin:
Further perhaps the PAM module could be configured to only allow certain
environment variables to be manipulated this way admins can control which
variables users can set.
/etc/ldap/pam_ldap.conf:
...
# allow
pam_allow_env_vars PATH,EDITOR
# deny
pam_deny_env_vars PATH,TZ
# wildcards? regex?
pam_allow_env_vars LC_*,PATH,EDITOR
pam_deny_env_vars TZ
So if we're storing environment variables in LDAP why not profiles or small
files? ~/.bashrc, ~/.my.cnf, ~/.ssh/config? Sure there's some overlap
with env vars because you could set them in your profile but with both
options an admin is free to choose.
I can think of a couple of ways to implement this.
1. create subortinate objects to the user object
dn: cn=~/.bashrc,uid=me,dc=example,dc=com
...
objectClass: posixAccountProfile
posixProfile: <octet string>
Advantages: The advantage of this setup is that the profileScript class
could contain any number of attributes, perhaps a modified time so that the
script isn't rewritten if the subordinate object hasn't been modified since
the script was last modified.
Disadvantages: Kinda kludgy. Extra objects (more lookups).
2. Use LDAP attribute options (See http://www.ietf.org/rfc/rfc2251.txt RFC
2251 "4.1.5. Attribute Description" if not familiar)
dn: uid=me,dc=example,dc=com
...
posixProfile;~/.bashrc: <octet string>
posixProfile;~/.my.cnf: <octet string>
Advantages: No extra objects, makes use of oft unused LDAP attribute
options :), can have ACI's applied to them.
Disadvantages: Only modified time to track is modified time of the LDAP
object not individual profileScript attrs
In both cases it might be wise to consider how file names are specified.
Perhaps leave off the ~/ and make everything relative to ~ no matter what.
Or make everything relative to ~/ even if it starts w/ a '/'. Maybe simply
reject anything that begins with '/'.
dn: uid=me,dc=example,dc=com
...
posixProfile;.bashrc: <octetString>
posixProfile;.foo/foorc: <octetstring>
Plus I don't know if / and . are legitimate characters in attribute options.
So thanks for sticking with me if you got this far. What do you think?
Regards,
-Alan