Re: slow su? [solved]
Ian D. Leroux
06:02:07 +0000):
> On Thu, Aug 11, 2011 at 09:11:41PM +0200, Ian D. Leroux wrote:
> > Otherwise, you're liable to get bitten someday when the old
> > kerberised PAM modules left behind by your first installation stop
> > working, the PAM stacks fail to load and su (and probably other
> > valuable bits of the system as well) refuse to run.
> >
> > This is implicit in the NOTES section of pam.conf(5), but easily
> > overlooked.
>
> See PR 40599...
Precisely. I take it that there has been no progress on the matter
in the last two years?
Being a stubborn fellow, I'll probably try commenting out all references
to pam_ksu and pam_krb5 in /etc/pam.d/* and see whether that improves
matters. If it does, perhaps an ed script to do the same could be run
as part of the build process when Kerberos is disabled?
Regards,
Ian Leroux
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
David Holland
> > On Thu, Aug 11, 2011 at 09:11:41PM +0200, Ian D. Leroux wrote:
> > > Otherwise, you're liable to get bitten someday when the old
> > > kerberised PAM modules left behind by your first installation stop
> > > working, the PAM stacks fail to load and su (and probably other
> > > valuable bits of the system as well) refuse to run.
> > >
> > > This is implicit in the NOTES section of pam.conf(5), but easily
> > > overlooked.
> >
> > See PR 40599...
>
> Precisely. I take it that there has been no progress on the matter
> in the last two years?
Yup. I was told that the fix I proposed (causing missing modules to
always fail) was unacceptable. Apparently the PAM semantics are so
fragile that any change to make it more robust also makes it fail open
in obscure ways, or something like that.
My opinion remains that PAM ought to go, but that's not trivial...
> Being a stubborn fellow, I'll probably try commenting out all references
> to pam_ksu and pam_krb5 in /etc/pam.d/* and see whether that improves
> matters. If it does, perhaps an ed script to do the same could be run
> as part of the build process when Kerberos is disabled?
It could; the problem (or a problem) is that because those files are
in /etc the process of updating them in already-installed systems is
"interesting".
--
David A. Holland
dhol...@netbsd.org
Christos Zoulas
David Holland <dholland...@netbsd.org> wrote:
>On Fri, Aug 12, 2011 at 09:55:12PM +0200, Ian D. Leroux wrote:
> > > On Thu, Aug 11, 2011 at 09:11:41PM +0200, Ian D. Leroux wrote:
> > > > Otherwise, you're liable to get bitten someday when the old
> > > > kerberised PAM modules left behind by your first installation stop
> > > > working, the PAM stacks fail to load and su (and probably other
> > > > valuable bits of the system as well) refuse to run.
> > > >
> > > > This is implicit in the NOTES section of pam.conf(5), but easily
> > > > overlooked.
> > >
> > > See PR 40599...
> >
> > Precisely. I take it that there has been no progress on the matter
> > in the last two years?
>
>always fail) was unacceptable. Apparently the PAM semantics are so
>fragile that any change to make it more robust also makes it fail open
>in obscure ways, or something like that.
This is not the problem... The problem is that a missing "binding",
"required", or "requisite" module should cause a failure, and most
modules are by design that.
>My opinion remains that PAM ought to go, but that's not trivial...
And replace it with what?
> > Being a stubborn fellow, I'll probably try commenting out all references
> > to pam_ksu and pam_krb5 in /etc/pam.d/* and see whether that improves
> > matters. If it does, perhaps an ed script to do the same could be run
> > as part of the build process when Kerberos is disabled?
>
>It could; the problem (or a problem) is that because those files are
>in /etc the process of updating them in already-installed systems is
>"interesting".
I don't think that is necessary if you don't have a krb5.conf file.
christos
John Nemeth
} On Fri, Aug 12, 2011 at 09:55:12PM +0200, Ian D. Leroux wrote:
} > > On Thu, Aug 11, 2011 at 09:11:41PM +0200, Ian D. Leroux wrote:
} > > > Otherwise, you're liable to get bitten someday when the old
} > > > kerberised PAM modules left behind by your first installation stop
} > > > working, the PAM stacks fail to load and su (and probably other
} > > > valuable bits of the system as well) refuse to run.
} > > >
} > > > This is implicit in the NOTES section of pam.conf(5), but easily
} > > > overlooked.
} > >
} > > See PR 40599...
} >
} > Precisely. I take it that there has been no progress on the matter
} > in the last two years?
}
} Yup. I was told that the fix I proposed (causing missing modules to
} always fail) was unacceptable. Apparently the PAM semantics are so
} fragile that any change to make it more robust also makes it fail open
} in obscure ways, or something like that.
If I recall right, my reading of the PAM spec was that it should
ignore missing modules, but I don't have the spec in front of me at the
moment. When I asked you about it, you just handwaved and said that
somebody you know that is supposedly a PAM expert said it would be a
bad idea without providing any details. I sure would like to know why
we shouldn't just follow the spec...
} My opinion remains that PAM ought to go, but that's not trivial...
That's like saying NFS ought to go. PAM is an expected part of a
modern OS and a lot of third party code uses it. At the very least,
you would need to provide the client side API. And, ideally, you would
need to provide some way of modularising authentication. There are
plenty of third party PAM module out there making PAM the ideal way.
Otherwise, you force people to make their own modules, and that could
cause people to discard NetBSD as a choice of OS.
In the pre-PAM days, I ended up using Redhat for a project because
it did have PAM and that made the project much easier. I would have
liked to have used NetBSD, but without PAM I would have had to do a lot
of custom coding.
} > Being a stubborn fellow, I'll probably try commenting out all references
} > to pam_ksu and pam_krb5 in /etc/pam.d/* and see whether that improves
} > matters. If it does, perhaps an ed script to do the same could be run
} > as part of the build process when Kerberos is disabled?
}
} It could; the problem (or a problem) is that because those files are
} in /etc the process of updating them in already-installed systems is
} "interesting".
It becomes the job of the person changing the system to make the
necessary adjustments.
}-- End of excerpt from David Holland
Roland C. Dowdeswell
>
> > > Being a stubborn fellow, I'll probably try commenting out all references
> > > to pam_ksu and pam_krb5 in /etc/pam.d/* and see whether that improves
> > > matters. If it does, perhaps an ed script to do the same could be run
> > > as part of the build process when Kerberos is disabled?
> >
> >It could; the problem (or a problem) is that because those files are
> >in /etc the process of updating them in already-installed systems is
> >"interesting".
>
> I don't think that is necessary if you don't have a krb5.conf file.
I think that we should comment out the PAM Kerberos modules in the
default install. Right now, we have hacked our Kerberos libraries
in a rather non-standard way to disable Kerberos if /etc/krb5.conf
is not present. I believe that this hack was instituted before
PAM when our various tools (login, su, etc.) would unconditionally
attempt to validate Kerberos passwds causing nameservice lookups
and unnecessary delays.
The unfortunate result of this decision is that on NetBSD, you
cannot use Kerberos without an /etc/krb5.conf. It is, however,
perfectly reasonable to be a Kerberos client without allowing
Kerberos logins on a box. In fact, this is how I generally setup
my laptops. It is also perfectly reasonable to run Kerberised
services on boxes which do not allow Kerberos passwd-based logins.
In fact, it is in general better to not allow Kerberos passwd-based
logins except on the console as in a Kerberised environment you
should not and should not have to broadcast your passwd to remote
machines.
So, I think that we should re-evaluate the PAM stacks, comment out
the Kerberos PAM modules from some, remove them from others and
remove the hack which disables Kerberos if /etc/krb5.conf is not
present. Services such as sshd should check if their keytabs
contain the appropriate keys before advertising that they support
Kerberos and perhaps PAM modules should be likewise instrumented.
--
Roland Dowdeswell http://Imrryr.ORG/~elric/
Ian D. Leroux
wrote:
Fair enough. How about I submit a documentation patch to mk.conf(5)
warning the user that such adjustments are necessary?
Ian Leroux
John Nemeth
} On Sat, 13 Aug 2011 16:23 -0700, "John Nemeth" <jne...@victoria.tc.ca> wrote:
} > On Jan 3, 1:21pm, David Holland wrote:
} > } On Fri, Aug 12, 2011 at 09:55:12PM +0200, Ian D. Leroux wrote:
} > } > Being a stubborn fellow, I'll probably try commenting out all references
} > } > to pam_ksu and pam_krb5 in /etc/pam.d/* and see whether that improves
} > } > matters. If it does, perhaps an ed script to do the same could be run
} > } > as part of the build process when Kerberos is disabled?
} > }
} > } It could; the problem (or a problem) is that because those files are
} > } in /etc the process of updating them in already-installed systems is
} > } "interesting".
} >
} > It becomes the job of the person changing the system to make the
} > necessary adjustments.
}
} Fair enough. How about I submit a documentation patch to mk.conf(5)
} warning the user that such adjustments are necessary?
Sure.
}-- End of excerpt from "Ian D. Leroux"