<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 07/10/2013 05:53 PM, Alan Evans wrote:
<blockquote
cite="mid:CAMFVOoX82ssvQaqCsHSBZ3Ys88nV2N3zbMheWu9zrnFOiXFF=Q@mail.gmail.com"
type="cite">
<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>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I might have looked at it in a more generic way as more system ENV
VARs than personal preferences.<br>
But here is a question. Are your preferences same on all systems?<br>
It seems that preferences should be more targeted to the groups of
systems rather than be a property of the user.<br>
What your are talking about here is effectively a roaming profile. I
think in Windows you can define which groups of systems the profile
roams between.<br>
<br>
I do not have any negative feelings about the idea of storing the
information in LDAP. But IMO it makes sense to view it more as a
user preferences. I would think that it should be something like:<br>
<br>
userPreferences: <JSON string> <br>
<br>
That would allow more flexibility and would not require protocol
changes to add new things as needed.<br>
And have it be associated with user-host pair. It is expressed by
association object class in IPA.<br>
<br>
But let us assume we say it is not a bad idea and can be done. What
is next?<br>
I can say for sure that we will not invest into changing pam_ldap to
support it. Only SSSD. Will it make the solution irrelevant for you?<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAMFVOoX82ssvQaqCsHSBZ3Ys88nV2N3zbMheWu9zrnFOiXFF=Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Freeipa-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>
</pre>
</body>
</html>