[Freeipa-users] [RFC] Feature idea - ENV vars/profile scripts in directory
Артур Файзуллин
arthur at deus.pro
Fri Jul 12 04:30:09 UTC 2013
If You will use automount of home dirs, it will allready centrelaised.
В Ср, 10/07/2013 в 15:53 -0600, Alan Evans пишет:
> 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.
>
>
> 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 <dpal at 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 at 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/
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
More information about the Freeipa-users
mailing list