On 07/10/2013 05:53 PM, Alan Evans wrote:
> Man I just can't seem to reply to this list correctly.  I hope the
> other two didn't actually go anywhere.
>
> Dimitri,
>
> I do not mean to store system environment variables but MY environment
> variables.

I might have looked at it in a more generic way as more system ENV VARs
than personal preferences.
But here is a question. Are your preferences same on all systems?
It seems that preferences should be more targeted to the groups of
systems rather than be a property of the user.
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.

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:

userPreferences: <JSON string>

That would allow more flexibility and would not require protocol changes
to add new things as needed.
And have it be associated with user-host pair. It is expressed by
association object class in IPA.

But let us assume we say it is not a bad idea and can be done. What is next?
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?




>
> dn: uid=alan,dc=example,dc=com
> objectclass: top
> objectclass: posixAccount
> objectclass: inetOrgPerson
> objectclass: posixAccountEnv
> ...
> uid: alan
> cn: Alan Evans
> posixEnv: EDITOR=vim
> # or
> posixEnv;EDITOR: vim
>
> 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.
>
> As for implementing it could be all done in pam_ldap which would be
> pretty easily portable.
>
> HTH,
> -Alan
>
>
> On Wed, Jul 10, 2013 at 3:20 PM, Dmitri Pal <d...@redhat.com
> <mailto:d...@redhat.com>> wrote:
>
>     On 07/10/2013 04:48 PM, Alan Evans wrote:
>>     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.
>>
>>     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
>>
>>
>>     _______________________________________________
>>     Freeipa-users mailing list
>>     Freeipa-users@redhat.com <mailto:Freeipa-users@redhat.com>
>>     https://www.redhat.com/mailman/listinfo/freeipa-users
>
>     I see couple problems but in a different plane.
>     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.
>     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.
>
>     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.
>
>     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:
>     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.
>     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.
>
>     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).
>
>
>     -- 
>     Thank you,
>     Dmitri Pal
>
>     Sr. Engineering Manager for IdM portfolio
>     Red Hat Inc.
>
>
>     -------------------------------
>     Looking to carve out IT costs?
>     www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
>     _______________________________________________
>     Freeipa-users mailing list
>     Freeipa-users@redhat.com <mailto:Freeipa-users@redhat.com>
>     https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to