On Sat, Oct 22, 2011 at 11:28:56AM -0500, Harry Coin wrote:
> >Do your NFS servers behave differently and call aname_to_lname()?
>
> Yes. Through a long chain winding in and out of the kernel eventually
> calling a userland daemon gssd.
It's funny if it is gssd which calls the mapping function
because the mapping belongs in nfsuserd, not in gssd.
IOW if it is gssd which does it, it is a bug. Oh well.
> If you take the time to focus on how and when the procedure with I bug I
> fixed gets called, you will comprehend.
> http://www.freebsd.org/cgi/query-pr.cgi?pr=161854
>
> and
> http://svnweb.freebsd.org/base/head/kerberos5/lib/libgssapi_krb5/pname_to_uid.c?revision=181344&view=markup
Yes I see. Using krb5_aname_to_localname() is a pity and in my eyes an
oversight in the NFS implementation. Anyway, thanks for explaining the
cause of your problem.
[This could be better fixed in the first hand by not using
krb5_aname_to_localname() and then applying configurable explicit rules
as desired for NFS instead. Note that the desired mapping for different
services (say, NFS and login and sudo) might be different so even if
the Kerberos library would offer the mapping configurable "per host",
it will not be able to fit the possibly contradictory needs of services.
Such mapping is by its nature application-specific, not library-specific.]
> >Note that there is a general and straightforward workaround - letting a
> >daemon use different Kerberos credentials for its own service and for
> >accessing the NFS service. This should be easy to setup (_is_ easy on
> >Linux, did not test on other client platforms).
>
> Ah if only. You'll note the kernel 'taint' process prevents drop-root
> services from doing anything of the sort. All credentials must be read
I told you that such behaviour is plainly wrong :)
Anyway, my approach on Linux looks as follows: start a process as the
desired uid, with a desired for NFS access keytab and let the process
(a shell script) loop and renew its credentials in a ccache where gssd
can find it (in the standard ccache directory on Linux).
No tricks, no drop-root idiosynchrasies.
Implementable easily e.g. by "sudo -u local_account the_script" as root
or by a very short C program if you like ultimate control in a small package.
Another process (a service daemon?) with the same uid may remain totally
unaware of this one and of its totally separate keytab, with a totally
different principal. Why wouldn't it work for you? (well, a crazy NFS
gssd implementation could make this impossible but this would be a
serious bug and would _have_ to be fixed).
> I've tried in the past, I don't know how to say it differently. Here
Sorry to have put this strain upon you.
Feel free to ignore my questions and I will not insist.
> Modify configuration files all month
> and still, no joy. Being that if it isn't happy, I'm out of a job,
...
> used without local changes and recompilations of any sort. And that in
> this instance is heimdal. Down at the roots of it all.
I feel your frustration.
> I suggest you try this: Get two boxes and a hub that are
> otherwise going to be thrown away. Load freebsd stable on one. Load
> whatever linux distro you prefer on the other. Do an nfs share, set
> up ldap/slapd on the freebsd box and run nslcd and make it the kdc.
This looks like a nice example.
> Now, on the linux box, set it up to be a client of the freebsd box.
> Mount an nfs share. Set up pam to use kerberos and get nslcd and
> nsswitch and so forth configured properly. Create some realm principals
> that don't have local accounts in the passwd database but only exist via
> ldap.
Ok. I can not help saying that "principals do not have accounts" :)
I guess you mean principals corresponding literally to unix accounts
present in LDAP but not in the local passwd databases.
> So, now you can do an ls -l on either system and see the proper owners
> of files created by anyone.
I would expect yes. In the reality I am happily accessing NFSv4 shares
with sec=krb5i from a FreeBSD-9beta server to Linux workstations.
> Now, here we go: Change the nfs share to require kerberos. No
> auth_sys for any part whatsoever. Change ldap so it can't do anonymous
> binds and must rely on sasl->gssapi->kerberos. Make it so ldapwhoami
> fails, and the only way it can work is ldapwhoami -Z
Not running LDAP in reality but I can follow your description, at least
mentally.
> Then, write back here with how you've formatted your principals, what is
> in your configuration files. Only then will I be able to see what it
> is you are trying to accomplish.
Nice. Now I have got some idea about what functionalitites you are after.
A disclaimer, I am doing a mental exercise and may miss vital details,
then please correct me.
First of all, human users will have each a principal in lowercase
latin letters without any '/', like the traditional unix account names.
The local passwd databases would be what the distro has created, I wouldn't
care. nss shall be set up so that a match in the local passwd returns
the result, otherwise a remote source is to be asked.
With other words nss config like
------
group: files ldap
passwd: files ldap
------
I would use ldap for nss only, not for authentication (of course).
Root passwd hash is to be present in the local passwd database.
Login (both local and ssh, nothing else) shall be governed by pam setup like
------------------
$ cat /etc/pam.d/sshd
#%PAM-1.0
auth include common
account required pam_listfile.so onerr=fail item=user sense=allow file=/somewhere/locally/who-is-authorized-for-ssh-here
account include common
password include common
session include common
------------------
(similar for login, pam_listfile is just a straightforward
example, groups, given nss_ldap can be a more flexible approach)
------------------
$ cat /etc/pam.d/common
#%PAM-1.0
auth required pam_env.so
auth [success=2 default=ignore] pam_unix.so likeauth nullok
auth [success=1 default=ignore] pam_krb5.so flags-go-here
auth required pam_deny.so
auth required pam_permit.so
account required pam_unix.so different-flavors-different-flags
account pam_krb5.so may-be-needed-here-to-produce-a-ccache-or-something
session required pam_limits.so
session required pam_unix.so
session optional pam_krb5.so ymmv-but-may-take-care-of-ccache-cleanup
session optional pam_script.so
------------------
(there are many variations of pam_krb5, see the relevant man page...)
I am letting aside pam setup for other local services like at/cron
(nothing to do with Kerberos) nor screensaver (which is a pita due to
PAM design, not Kerberos-specific)
in nss_ldap.conf:
------------------
use_sasl on
sasl_secprops minssf=112
sasl_authid nss_auth_client
sasl_mech GSSAPI
sasl_authcid ldapd/[email protected]
krb5_ccname FILE:/locally/where-you-deem-appropriate
------------------
Ensure that you populate the ccache and refresh it regularly,
with something like
kinit -t /locally/ldapd-keytab -c /locally/where-you-deem-appropriate
A similar thing for slapd, I guess you know better than me how to
configure sasl authentication, specify the mech, the service identity,
the keytab and also allow read access to the LDAP database for sasl
(Kerberos) identities of your ldapd(s) of all boxes. I do not see any
mapping between local and Kerberos identities involved in such setup.
Of course you allocate an uid for each kind of daemon and put it in the
local passwd database on the machine running the daemon. The account
name does not matter as long as it does not collide with your users'
account names.
Each daemon uid shall of course have a separate keytab.
Of course, we will suffer if slapd is doing set*uid() which triggers the
library's paranoia. I'd plainly patch the library (which is the cause of
the problem) and remove that paranoia. Another remedy is to look over
the daemon's startup scripts and let it avoid the changes between uids
if possible. I haven't tried. It may need extra powers for listening on
"reserved" ports (another example of hardly useful paranoia).
If you configure your LDAP service for higher ports you may be able
to run slapd as non-root from the beginning. As you use Kerberos for
authentication, you would not lose any security by such a move. In fact,
this looks like a nice possibility.
Note that ldapd seems to be immune to set*uid(), because it reads where
to find the credentials from a config file, not from the environment.
What else? Your users access NFS without a problem, you can log in as root
locally or remotely using the "locally hashed" password. If you wish add a
pam_krb5 alt... flag to use root/[email protected] for ssh remote login
(giving the principal's Kerberos passwd). If you wish a passwordless
root login with help of Kerberos credentials then it is a separate issue.
So, where is a problem besides the undue library paranoia?
As the experiment is mental I may miss actual bugs or limitations
in the software involved but I guess all the above should work.
Going offtopic Kerberos but for completeness:
Instead of using LDAP you can rely on the local passwd/group database
on the NFS server containing all users and groups and let pam_script on
the clients create passwd entries (locally, with independently assigned
uids) at login. If you never remove entries from the database on the
NFS server (account names SHOULD be reserved forever for other reasons)
you never will go out of sync. This works. The downside is that ls will
not show the ownership of files belonging to accounts never logged in
on the actual computer, nor the non-personal groups. If it is an issue,
then use LDAP as above.
In any case, you should also choose procedures to maintain access lists
for login to different computers by different means and for different
(human) accounts. Note that even if accounts are created locally
on-the-fly, their names shall be present in a login acl in advance.
Regards,
Rune
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.