i need kerberos support in a few packages, but being lazy, i just added it system wide (so i wouldnt also have to worry about USE deps). recently, pam_krb5 was added as a dep to pambase when USE=kerberos. since this system also has USE=pam, it was pulled in. i have no need for kerberos support in pam, but whatever, it shouldnt be a problem since i never configured it. this being a laptop, i move between networks. i needed to reconfigure my settings, so i did `sudo su -`. and waited. and waited. because my dns was unreachable, the pam_krb5 module kept attempting to lookup the dns name "_kerberos" over and over again and apparently pam_krb5 is now in the default pam stack for consultation. so my `sudo su -` took forever. similarly, i disable "UseDNS" in my sshd server for preciously this reason. when i need to pop into the machine but DNS is unreachable (or useless on a LAN), a reverse DNS is just noise/problems. but now my ssh connections too take a few minutes to simply get to a password prompt. pam_krb5 should not be consulting anything by default (such as the network). if it cannot be configured as such, then pambase should not be pulling it in via USE=kerberos. if people need this package, they should emerge it themselves. while i havent done an audit or too much testing, blindly looking up "_kerberos" via DNS sounds lie a security issue. who is to say the DNS doesnt bounce "_kerberos" to its own system and watch the traffic ? my shitty ISP (comcast) certainly redirects all unknown DNS results to their own machines.
Kerberos defaults are tackled by Kerberos team.
(In reply to comment #0) > i need kerberos support in a few packages, but being lazy, i just added it > system wide Don't do it. This is rarely a good choice and almost never the correct choice for a laptop. > pam_krb5 should not be consulting anything by default (such as the network). Anything kerberos related above a few computers quickly becomes unmanageable without DNS lookups. > pambase should not be pulling it in via USE=kerberos. if people need this > package, they should emerge it themselves. Actually no, one should not be turning on kerberos USE flag globally (and blindly?). But pragmatically, I agree with the above statement because this is a rather lost cause and this issue will continue to come up. pambase should not have the kerberos USE flag as pam_krb5 has a rather small audience who presumably know what they are doing and can add it to pam.d as they see fit - which will more than likely be modified accordingly to site policy. But I believe flameeyes feels differently and pambase is his ball - and strictly speaking he is correct. > while i havent done an audit or too much testing, blindly looking up > "_kerberos" via DNS sounds lie a security issue. No. The whole point of kerberos is secure auth thru untrusted networks. To sum up, your alternatives: 1. Convince flameeyes to drop kerberos USE flag from pambase (too late now). 2. Do not add kerberos USE flag globally. 3. Disable pam_krb5 in your /etc/pam.d/system-auth. #2 is the correct solution while #3 is the practical one. Closing. Please reopen if you feel differently.
Just to say there is a fourth option: get Portage to respect a negative USE default (IUSE="-kerberos") so that even if kerberos is enabled globally, pambase still have to be explicitly enabled via package.use. I remember asking Zac about it but it was complex and thus low priority. Sincerely, that would be my preferred solution.
IUSE=-foo is already supported and controlled via USE_ORDER so let's get pam_krb5 dropped from pambase. the policy in Gentoo is the installed defaults "just work". pam_krb5 does not fit that, so it should either be fixed or mitigated. removing from pambase falls into the "mitigated" category.
I'm not going to disable it. Even though it doesn't just drop in (and if you want to go that route, you have a number of things to go drop around the tree), this already provides a starting situation. I don't want to deal with people adding Kerberos support to PAM with random order and classes, as that will open bigger cans of worms. Just look at how not even the gnome team could get GDM to play it right with gnome-keyring. Or the fact that you even broke login for all users by ignoring a change of mine to shadow two years ago. And this is without factoring in the wrong suggestions given in postinst by older modules ebuilds. You said you don't care to PAM; Eray doesn't like it but admit he wouldn't take the weight of pambase himself; I'm going to stick to my "if you don't use Kerberos, you don't USE=kerberos"…
you might want to review actual history. i could care less about USE=pam in shadow, so any changes not going in were due to an outdated tree. ive never "ignored" any pam changes in shadow to the tune of dropping them. simply change the pam_krb5 default dns lookup from "_kerberos" to "localhost" then if people insist on keeping it active even when unconfigured & useless
You do check when you committed a shadow version from a local copy without adapting a newpam call for the login configuration file. Eray, what's your take? If it's safe enough and doable, I'm fine, I just _don't_ want to drop kerberos support and risk people add it wrong.
which part dont you get ? "ignoring" is not the same thing as "accidentally copying an older ebuild from an out of date tree".
A compromise might be to rename the kerberos USE flag to krb5 or similar in pambase. Flameeyes? @vapier: Changing default dns lookup from "_kerberos" to "localhost" is not a realistic solution. _kerberos is specified in RFCs, hard coded in all the kerberos client programs I have seen, would impair interoperability and surprise the heck out of the sysadmins who use Gentoo kerberos. What one can do is edit /etc/hosts and /etc/krb5.conf files so that DNS lookups are not necessary for kerberos. Beware tho: This is not really workable outside of a test lab and MIT - and to a lesser extend Heimdal - are hoping to phase out the listing of server hostnames in client-side configuration files.
when authing, my log shows: [sudo] pam_krb5(sudo:auth): (user vapier) krb5_parse_name failed: Configuration file does not specify default realm that implies that pam_krb5 cannot work unconfigured. so why cant it do this checking *before* the network traffic ?
(In reply to comment #10) > krb5_parse_name failed:[...]that implies that pam_krb5 cannot work > unconfigured. Not really. It implies kerberos cannot work unconfigured. pam_krb5 uses standart kerberos libraries for most of its work. $ nm -D /usr/lib/libkrb5.so.3.3 |grep krb5_parse_name 0005adc0 T krb5_parse_name 0005ada0 T krb5_parse_name_flags $ equery belongs libkrb5 [ Searching for file(s) libkrb5 in *... ] app-crypt/mit-krb5-1.8.3-r1 (/usr/lib/krb5/plugins/libkrb5) > so why cant it do this checking *before* the network traffic ? When no realm info is provided, krb5_parse_name() calls krb5_get_default_realm() which in turn does the DNS lookup if it cannot find an appropriate entry in the configuration file. It is possible to suppress the DNS lookup (via the KRB5_DNS_LOOKUP macro) but it will be for the whole kerberos library (not for pam_krb5 alone) which is a no-go for all intents and purposes. Vapier, this is a known problem with no good solution currently. Using pam_krb5 on computers that can be disconnected from the network is not a good idea. Hence my request to not to pull it in with a global USE flag (either drop it from pambase or change the USE flag name). Until then, edit the config file(s) for the laptops.
removing the crap from my computer isnt a problem. if that was the only thing i was interested in, i wouldnt have filed a bug. this default behavior is undesirable for everyone, hence the bug to try and get it resolved for everyone.
28 Nov 2010; Constanze Hausner <constanze@gentoo.org> pambase-20090620.1-r1.ebuild, pambase-20100310.ebuild, pambase-20100925.ebuild, pambase-20101024.ebuild, metadata.xml: Renamed useflags ssh/kerberos to pam_ssh/pam_krb5 and changed kerberos dep to >=sys-auth/pam_krb5-4.3 Thank you.
hmm, as another idea ... i can understand Diego's desire to code pam_krb5 into the standard pam.d files to avoid duplication/screw ups with other packages, but why exactly does pambase even need to depend on pam_krb5 at all ? if the module isnt available, wont pam simply ignore it ? so USE=kerberos could stay in place with pambase, but if people actually want to auth against it, they simply need to emerge the package.
Main reason being that (minus a screw up of mine forgetting about it first time around) we use the dependency to enforce a minimum version. Case in point, Sabayon does not have pam_krb5 4.3 or later, if they get pambase with the USE enabled, you get unable to login, worse than what you experienced. The same reason why I have forced gnome-keyring/consolekit/stuff dependencies: wrong versions can be just as bad as misconfiguration.
that can be handled by a blocker without forcing other people to install it
