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 <[email protected] > <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> 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 > [email protected] <mailto:[email protected]> > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > _______________________________________________ > Freeipa-users mailing list > [email protected] > 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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
