<div dir="ltr">Man I just can't seem to reply to this list correctly. I hope the other two didn't actually go anywhere.<br><br><div><div><div><div><div><div><div><div><div><div>Dimitri,<br><br></div>I do not mean to store system environment variables but MY environment variables.<br>
<br></div>dn: uid=alan,dc=example,dc=com<br></div>
objectclass: top<br></div><div>objectclass: posixAccount<br></div><div>objectclass: inetOrgPerson<br></div><div>objectclass: posixAccountEnv<br>...<br></div>uid: alan<br></div>cn: Alan Evans<br></div>posixEnv: EDITOR=vim<br>
</div><div># or <br></div><div>posixEnv;EDITOR: vim<br></div><div><br></div>In
my opinion while these do not necessarily meet the definition you just
described they are distinctly MY preferences and I would argue they
belong with my object in LDAP. Storing some environment variables isn't
that different from storing my preferred shell, or my preferred contact
information and so on.<br>
<br></div>As for implementing it could be all done in pam_ldap which would be pretty easily portable.<br><br></div>HTH,<br></div>-Alan<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 3:20 PM, Dmitri Pal <span dir="ltr"><<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
On 07/10/2013 04:48 PM, Alan Evans wrote:
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>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.<br>
<br>
</div>
</div>
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.<br>
<br>
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.<br>
<br>
</div>
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?<br>
<br>
Maybe this modified
pam_ldap could do things
like append, remove,
replace or unset
environment variables.
Consider:<br>
<br>
</div>
dn: uid=me,dc=example,dc=com<br>
</div>
<div>objectClass:
posixAccountEnv<br>
</div>
<div>...<br>
</div>
# replace EDITOR<br>
</div>
<div>posixEnv: EDITOR=vim<br>
</div>
<div># unset TZ<br>
</div>
posixEnv: TZ-=<br>
</div>
<div>
# append PATH<br>
</div>
posixEnv: PATH=+:~/bin<br>
</div>
<div># prepend PATH<br>
</div>
<div>posixEnv: PATH+=/opt/foo/bin:<br>
</div>
<br>
</div>
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.<br>
<br>
</div>
<div>/etc/ldap/pam_ldap.conf:<br>
...<br>
</div>
<div># allow<br>
</div>
<div>pam_allow_env_vars PATH,EDITOR<br>
</div>
<div># deny<br>
</div>
<div>pam_deny_env_vars PATH,TZ<br>
</div>
<div># wildcards? regex?<br>
</div>
<div>
pam_allow_env_vars LC_*,PATH,EDITOR<br>
</div>
<div>pam_deny_env_vars TZ<br>
</div>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
I can think of a couple of ways to
implement this.<br>
</div>
1. create subortinate objects to the user
object<br>
</div>
dn: cn=~/.bashrc,uid=me,dc=example,dc=com<br>
...<br>
</div>
objectClass: posixAccountProfile<br>
</div>
posixProfile: <octet string><br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>Disadvantages: Kinda kludgy. Extra objects
(more lookups).<br>
</div>
<div><br>
</div>
2. Use LDAP attribute options (See <a href="http://www.ietf.org/rfc/rfc2251.txt" target="_blank">http://www.ietf.org/rfc/rfc2251.txt</a>
RFC 2251 "4.1.5. Attribute Description" if not
familiar) <br>
</div>
dn: uid=me,dc=example,dc=com<br>
...<br>
</div>
posixProfile;~/.bashrc: <octet string><br>
</div>
posixProfile;~/.my.cnf: <octet string><br>
<br>
</div>
Advantages: No extra objects, makes use of oft unused LDAP
attribute options :), can have ACI's applied to them.<br>
Disadvantages: Only modified time to track is modified
time of the LDAP object not individual profileScript attrs<br>
<br>
</div>
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 '/'.<br>
<br>
dn: uid=me,dc=example,dc=com<br>
...<br>
</div>
posixProfile;.bashrc: <octetString><br>
</div>
posixProfile;.foo/foorc: <octetstring><br>
<div>
<div><br>
Plus I don't know if / and . are legitimate characters in
attribute options.<br>
<br>
</div>
<div>So thanks for sticking with me if you got this far. What
do you think?<br>
<br>
</div>
<div>Regards,<br>
</div>
<div>-Alan<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
Freeipa-users mailing list
<a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre>
</blockquote>
<br>
I see couple problems but in a different plane.<br>
1) You are talking about the server storing this data, it is not
standard but extension can be made. The bigger problem is the
client. Creating the client and porting it to multiple distros is a
challenge. SSSD is in Linux but not in classical UNIXes. As you
start looking at the client side effort solutions like Puppet, Chef
and friends become much more attractive.<br>
2) Which ENV vars need to be served to which groups of hosts. You
need the infrastructure to define and manage it. Puppet, Chef and
others are already good at it. <br>
<br>
So I am not really sure that adding the suggested data to LDAP is
the right place. LDAP is just a storage format and client protocol.
This is the smallest part of the effort. This would effectively lead
to duplicating some of existing management systems.<br>
<br>
We discussed things like that several years ago when we were
starting IPA project. We needed to draw the line about what to store
and what not to store in LDAP. We came up with a following
definition:<br>
Store things that are either traditionally stored in LDAP and
already have LDAP schema of some sort, store things that are dynamic
and must be looked up on the fly because security decision or
configuration relies on it.<br>
That leaves LDAP to be storage of identities (user, groups, hosts,
host groups) and remappings of those identities to the externally
managed objects, i.e. user(s) to command(s) = sudo, user(s) to host
access = HBAC, user(s) to SELinux policies = SELinux user mappings,
users and hosts to SSH keys = SSH integration.<br>
<br>
So realistically you might want to have something similar to what we
have for SELinux user mapping that would deliver a "tag" to a host
and then pass it to some pam module that would configure system
using that tag or use this tag to fetch something from a central
policy server. But that would again require a client and server
change and if you want it to be available on multiple platforms you
face the same challenge as in 1).<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<pre cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
<a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a>
</pre>
</font></span></div>
<br>_______________________________________________<br>
Freeipa-users mailing list<br>
<a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br></blockquote></div><br></div>