2:27 p.m.
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(a)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
2:31 p.m.
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
3:04 p.m.
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
--
Stephen John Smoogen | CCN-5 Security Team
LANL SIRT Team Leader | SMTP: smoogen(a)lanl.gov
Los Alamos National Laboratory | Voice: 505.664.0645
Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793
Los Alamos, NM 87545 |
3:12 p.m.
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 ?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
3:32 p.m.
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
4:07 p.m.
On Fri, 24 Sep 2004 16:32:01 -0400, Nalin Dahyabhai <nalin(a)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.
--
Stephen J Smoogen.
Professional System Administrator
4:23 p.m.
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(a)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
5:12 p.m.
New subject: Disconnect Login (Was: FC3 Bug Week - HELP WANTED)
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.
--
John Dennis <jdennis(a)redhat.com>
5:20 p.m.
New subject: Disconnect Login (Was: FC3 Bug Week - HELP WANTED)
On Fri, 2004-09-24 at 18:12, John Dennis wrote:
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.
opps ... pardon me, not nsswitch, but rather nscd, and yes the caching
support is in FC3.
--
John Dennis <jdennis(a)redhat.com>
5:19 p.m.
Talked to Nalin off-line. This is definately an RFE because of the
basic ideas behind kerberos account management.
--
Stephen J Smoogen.
Professional System Administrator
4:56 p.m.
New subject: Xinerama & tasklist Was: FC3 Bug Week - HELP WANTED
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.
--
Rudi
4:56 a.m.
New subject: Xinerama & tasklist Was: FC3 Bug Week - HELP WANTED
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:
http://bugzilla.gnome.org/show_bug.cgi?id=98698
I'll do a release upstream of libwnck and include it before the next
freeze.
Cheers,
Mark.
7173
days inactive
7176
days old
11 comments
8 participants
participants (8)
-
John Dennis -
Mark McLoughlin -
Nalin Dahyabhai -
Rik van Riel -
Rudi Chiarito -
seth vidal -
Stephen John Smoogen -
Stephen Smoogen