mjhjmtu

I need to set $PATH for OpenLDAP users (CentOS6/7). Not in .profile, not in .bashrc on client machine, but as attribute in LDAP on the LDAP server so it is set whenever the user logs onto any host via ssh. Nothing on client side -- LDAP server only. Is it possible? How to do it?

An LDAP directory only stores data, you need the LDAP client layer (e.g. pam_ldap) to do things with it. Unlike NetWare/ActiveDirectory, having a login script in the directory as a user property isn't a standard thing in other environments, and there is no standard attribute to store [a path to] such a script (though labelledURI is a candidate).

With PAM+NSS, only a handful of "databases" which you can point to LDAP are supported (passwd, groups, etc see nsswitch.conf(5)) none of which might make this easier.

Neither PADL pam_ldap nor nss-pam-ldap offer any flexible kind of LDAP attribute processing beyond filling out the basic getpwent() password structure fields.

But, there are perhaps a couple of workarounds, though none can meet your "nothing on client side" requirement.

1. Use pam_exec or pam_script, as these are run as child processes of login they cannot effect environment changes directly, but you could script something that made sure that the correct PATH always appeared within or at the end of .profile (depending on robustness requirements)




2. Use /etc/profile to fetch user attributes from LDAP, then set PATH accordingly (though you may find it tricky to prevent .profile overwriting it)




3. Modify pam_unix to allow and support misuse of the loginShell attribute prefixed with variables, like PATH=/opt/thing/bin /bin/bash (will not work with PADL, AFAICT)




4. Modify pam_umask, the Linux PAM pam_umask already processes extra information from the gecos field like "umask=nnnn,ulimit=nnnn" so there's some precedent here.




5. Modify pam_ldap to save LDAP attributes as PAM "data" via pam_set_data(), then use pam_get_data() in another PAM module to process them (I did this a long time ago, in my case it was to create users on-demand in an SQL user database using details from their LDAP attributes). pam_env is a good candidate here.




6. There's a similar concept for PAM "items" (pam_set_item()/pam_get_item()) for a small set of data items (the previous PAM data concept is for arbitrary name/value data), pam_env supports a syntax of @PAM_itemname to set environment values using these - you might be able to misuse an item like PAM_XDISPLAY. pam_ldap already sets a handful of items, so this is likely the simplest code change.

(To be clear, by "modify" I mean "change the source", so those solutions entail both configuration and binary deployments on clients.)

Here's a (robust-ish) bash example that could be made to work with the first two options:

 while read line; do
 [[ "$line" =~ ^description: setenv ([a-zA-Z_][a-zA-Z0-9_]+)=(.*) ]] && 
 export "$BASH_REMATCH[1]"="$BASH_REMATCH[2]"
 
 done < <(ldapsearch -LLL -o ldif-wrap=no -H ldap://ldap0/ -b $LDAPBASE 
 -s sub "(&(objectClass=posixAccount)(uid=$USER))" description

given one or more "description" attributes per-user of the form:

setenv MYVAR=MYVALUE

Here we're engaging in the dubious practise of stuffing non-description data into the "description" attribute, a handy way to store up to 1024 characters in a multi-valued attribute. This is a simple approach, using ldapsearch you will likely run into trouble if/when values/types cause base64 encoding output.

Problem solved, althrough not the way I wanted.
Used puppet to populate .profile files containing export PATH=$PATH:/xxxxxxxx directive.
Combined with removal of ldap entry "shell=binbash" it enabled correct setting of PATH variable.

Thank you for your extensive answer mr spuratic, it was a pleasure to delve into the matter.