The Fedora Core 3 freeze is coming soon, so it's time again for the frantic activities of a Bug Week. This time with community participation. The idea is to fix as many bugs as possible in the week from Sunday, September 26th till Friday, October 1st. Yes, it starts this weekend...
The goal of Bug Week is to fix as many of the annoying bugs out there as possible, so Fedora Core 3 ends up being a nice distribution without rough edges. We're going for quantity here, trying to fix all the easily fixable bugs that annoy users. Of course, if you have a fix for a harder to resolve problem, you're more than welcome to contribute it!
Developers: you can help by fixing bugs and reviewing the proposed fixes that other people mail to the fedora-patches-list, or that get attached to bugzilla. Packaging bugs are another category where we can use your help. Testers: you can help by verifying whether old bugs are still present in rawhide, as well as by testing proposed fixes sent in by developers. Bug triagers: you can help by gathering information on NEEDINFO bugs, as well as by helping assess the importance of bugs. Everybody: this is a chance to get the bugs fixed that you care about!
Developers from all engineering groups in Red Hat are standing by to fix bugs together with you, to apply submitted bug fixes and to make test RPMs available on the Bug Week repositories.
To participate in Bug Week, you can use the normal channels of communication:
- For discussion: fedora-devel-list, fedora-tools-list, fedora-test-list - For proposed patches: fedora-patches-list (so others have a chance of reviewing the proposed patches and verifying that they are ok) - For verified patches: bugzilla (to keep track of the patch) - IRC: #fedora-bugweek on irc.freenode.net
If you want to nominate a bug for being fixed this Bug Week, please send an email to me (riel@redhat.com) and the owner of the bug that you want to nominate for the Bug Week must-fix list. Note that bugs will only be accepted for the Bug Week must-fix list if there is a realistic chance of fixing them this week.
More information will be available soon, on: http://bugweek.fedora.redhat.com/
Developers, remember to subscribe to fedora-patches-list: http://www.redhat.com/mailman/listinfo/fedora-patches-list
You can track our progress on the FC3 Bug Week Tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FC3BugWeekTracker
Developers: you can help by fixing bugs and reviewing the proposed fixes that other people mail to the fedora-patches-list, or that get attached to bugzilla. Packaging bugs are another category where we can use your help. Testers: you can help by verifying whether old bugs are still present in rawhide, as well as by testing proposed fixes sent in by developers. Bug triagers: you can help by gathering information on NEEDINFO bugs, as well as by helping assess the importance of bugs. Everybody: this is a chance to get the bugs fixed that you care about!
I hope that the bugs people will be filing will be BUGS and not RFEs. Bugweek should not be about ranting about your most desired feature.
-sv
seth vidal wrote:
Developers: you can help by fixing bugs and reviewing the proposed fixes that other people mail to the fedora-patches-list, or that get attached to bugzilla. Packaging bugs are another category where we can use your help. Testers: you can help by verifying whether old bugs are still present in rawhide, as well as by testing proposed fixes sent in by developers. Bug triagers: you can help by gathering information on NEEDINFO bugs, as well as by helping assess the importance of bugs. Everybody: this is a chance to get the bugs fixed that you care about!
I hope that the bugs people will be filing will be BUGS and not RFEs. Bugweek should not be about ranting about your most desired feature.
Is having pam_krb5 not kill your login process when you have a local password and pam_krb5 is listed as optional... a bug or an RFE?
-sv
On Fri, 24 Sep 2004, Stephen J Smoogen wrote:
Is having pam_krb5 not kill your login process when you have a local password and pam_krb5 is listed as optional... a bug or an RFE?
Not sure. Nalin ?
On Fri, Sep 24, 2004 at 04:12:00PM -0400, Rik van Riel wrote:
On Fri, 24 Sep 2004, Stephen J Smoogen wrote:
Is having pam_krb5 not kill your login process when you have a local password and pam_krb5 is listed as optional... a bug or an RFE?
Not sure. Nalin ?
In all seriousness, that depends on what you mean by "kill". Crash? Bug. Access denied? If it's a legitimate denial, not a bug because the alternative could be far worse.
I did a spot-check with today's Raw Hide and 'login', and it worked for me (I had to give pam_unix the "use_first_pass" argument to avoid getting two password prompts), so please include as much about your configuration as you can.
Nalin
On Fri, 24 Sep 2004 16:32:01 -0400, Nalin Dahyabhai nalin@redhat.com wrote:
On Fri, Sep 24, 2004 at 04:12:00PM -0400, Rik van Riel wrote:
On Fri, 24 Sep 2004, Stephen J Smoogen wrote:
Is having pam_krb5 not kill your login process when you have a local password and pam_krb5 is listed as optional... a bug or an RFE?
Not sure. Nalin ?
In all seriousness, that depends on what you mean by "kill". Crash? Bug. Access denied? If it's a legitimate denial, not a bug because the alternative could be far worse.
Ok the original bug was 79853. I dont remember closing it.. but it looks like I did. I also thought I answered Nalins question on that bug.. but I cant find that either.. my apologies Nalin.
To give you an answer, I get a hang that does not return and login finally kills itself.
What I have been trying to do is get our laptops set up so that they can get kerberos tickets if they are on the domain, and not to get them if they are not. The problem is currently most seen in
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so account [default=bad success=ok user_unknown=ignore service_err=ignore syste m_err=ignore] /lib/security/$ISA/pam_krb5.so
password required /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_krb5.so use_authtok password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so
When the laptop is plugged into the network and a local password is used the access occurs. When I unplug the box but move the settings to even optional.. it just sits for 2 minutes and login times out.
This is really a RHEL-4/Fedora issue with us as it not working in RHEL-3 has been a 'reason to use something not so broken' as others have put it. I have been told that Fedora-Core Beta 2 is showing it too.. but I have to go through some paperwork to bring up a non-beta machine on our network. I will know on Monday.
On Fri, Sep 24, 2004 at 03:07:56PM -0600, Stephen J. Smoogen wrote:
On Fri, 24 Sep 2004 16:32:01 -0400, Nalin Dahyabhai nalin@redhat.com wrote:
On Fri, Sep 24, 2004 at 04:12:00PM -0400, Rik van Riel wrote:
On Fri, 24 Sep 2004, Stephen J Smoogen wrote:
Is having pam_krb5 not kill your login process when you have a local password and pam_krb5 is listed as optional... a bug or an RFE?
Not sure. Nalin ?
In all seriousness, that depends on what you mean by "kill". Crash? Bug. Access denied? If it's a legitimate denial, not a bug because the alternative could be far worse.
Ok the original bug was 79853. I dont remember closing it.. but it looks like I did. I also thought I answered Nalins question on that bug.. but I cant find that either.. my apologies Nalin.
No worries. It may have been happened in a private email, I think we've exchanged a few of those.
To give you an answer, I get a hang that does not return and login finally kills itself.
Given the configuration file you listed, I'd suspect a network timeout in the account management check (either attempting to resolve the KDC's host name, or in contacting the KDC).
Disabling such a check adds the risk of not denying access to someone for whom access should be denied, so that's not something I can recommend as a general solution -- unlike the authentication check, where any module can give the user a thumbs-up, for account management you need for any module to be able to torpedo the user's login attempt.
The timeouts in libkrb5 aren't adjustable, either, at least not if you're playing by the rules (and maybe not at all in 1.3 -- I last looked at this part of it in 1.2), so I don't really have a good answer for this problem.
HTH,
Nalin
On Fri, 2004-09-24 at 17:07, Stephen J. Smoogen wrote:
What I have been trying to do is get our laptops set up so that they can get kerberos tickets if they are on the domain, and not to get them if they are not. The problem is currently most seen in
When the laptop is plugged into the network and a local password is used the access occurs. When I unplug the box but move the settings to even optional.. it just sits for 2 minutes and login times out.
We added a new pam module in FC3 called pam_ccreds from PADL software. "CCreds" stands for "Cached Credentials". This may do what you want.
The pam ccreds (Cached Credentials) is an optional pam module that would only be turned on by explicit root configuration. It works by caching in an encrypted form the credentials from a successful login. The encrypted cache is readable only by root making it equivalent to the shadow mechanism. The idea is that if an organization is using server based authentication (e.g. NIS or LDAP) and the user disconnects from his network he should still be able to login to his notebook. The cache is only consulted if a server based pam module reports its server is unavailable. If a server while connected ever reports a positive NAK on authentication the users cached credentials are immediately flushed, this means a user does not have unlimited future ability to authenticate if his privileges are revoked on his network. He can only authenticate while disconnected and only if the previous connected authentication was successful. This provides a good trade off between security and practical real world access for mobile users.
There are few additional issues you will need to take into account:
1) authconfig needs to be patched to support ccreds, I don't think that patch made it into FC3.
2) User id information (e.g. nsswitch) still has to come from some place. If its currently network served you'll have problems. Rumor has it that FC3 picked up support for caching this, but at the immediate moment I'd don't have the details at my fingertips.
3) Home dirs will have to be local (we are in the process of adding support for home dir caching).
4) The network timeouts for the krb server won't occur if the network is turned off as opposed to unavailable (e.g. service network stop). There was a bug in the pam_krb5 which returned the wrong error code when the krb server was unavailable, it used to return "authentication failure" instead of the correct "server unavailable". That was fixed and I'm pretty sure is in FC3.
On Fri, 2004-09-24 at 18:12, John Dennis wrote:
- User id information (e.g. nsswitch) still has to come from some
place. If its currently network served you'll have problems. Rumor has it that FC3 picked up support for caching this, but at the immediate moment I'd don't have the details at my fingertips.
opps ... pardon me, not nsswitch, but rather nscd, and yes the caching support is in FC3.
Talked to Nalin off-line. This is definately an RFE because of the basic ideas behind kerberos account management.
On Fri, Sep 24, 2004 at 02:04:43PM -0600, Stephen J Smoogen wrote:
Is having pam_krb5 not kill your login process when you have a local password and pam_krb5 is listed as optional... a bug or an RFE?
In the same vein, is preventing the tasklist (wnck) from showing windows that are on other monitors a bug or an RFE?
I could only find a report upstream - and it seems to be fixed in CVS for 2.8.1:
http://bugzilla.gnome.org/show_bug.cgi?id=98698
The current behaviour can become truely unnerving.
Hi,
On Fri, 2004-09-24 at 22:56, Rudi Chiarito wrote:
On Fri, Sep 24, 2004 at 02:04:43PM -0600, Stephen J Smoogen wrote:
Is having pam_krb5 not kill your login process when you have a local password and pam_krb5 is listed as optional... a bug or an RFE?
In the same vein, is preventing the tasklist (wnck) from showing windows that are on other monitors a bug or an RFE?
I could only find a report upstream - and it seems to be fixed in CVS for 2.8.1:
I'll do a release upstream of libwnck and include it before the next freeze.
Cheers, Mark.