5:28 p.m.
On 12/17/05, Tomas Mraz <tmraz(a)redhat.com> wrote:
Actually all long running services using PAM have to be restarted after
this upgrade as the new modules won't work with the old library which is
already loaded into the process.
A pam update just rendered my entire test system unusable. I couldn't
login, I couldn't get out of gnome-screensaver's lock, I couldn't ssh
in, and I couldn't start up the computer in runlevel 3 or 5 any more.
In the end I managed to resolve it by booting into runlevel 1, going
into /var/cache/yum/development/packages and manually running: rpm
-Uvh pam*.rpm
It appears as though yum only partially updated pam, removing
/lib/libpam.so.0.80 but something went seriously wrong before it was
able to install the new libpam.so.
I hope that anyone else that has this problem can use this information
to repair their system.
n0dalus.
5:36 p.m.
On Sat, 2005-12-17 at 09:58 +1030, n0dalus wrote:
On 12/17/05, Tomas Mraz <tmraz(a)redhat.com> wrote:
>
> Actually all long running services using PAM have to be restarted after
> this upgrade as the new modules won't work with the old library which is
> already loaded into the process.
>
A pam update just rendered my entire test system unusable.
Thanks for the heads up.
6:08 p.m.
--- n0dalus <n0dalus+redhat(a)gmail.com> wrote:
A pam update just rendered my entire test system
unusable. I couldn't
login, I couldn't get out of gnome-screensaver's
lock, I couldn't ssh
in, and I couldn't start up the computer in runlevel
3 or 5 any more.
In the end I managed to resolve it by booting into
runlevel 1, going
into /var/cache/yum/development/packages and
manually running: rpm
-Uvh pam*.rpm
It appears as though yum only partially updated pam,
removing
/lib/libpam.so.0.80 but something went seriously
wrong before it was
able to install the new libpam.so.
I hope that anyone else that has this problem can
use this information
to repair their system.
Merely rebooting the system will cure your problem.
Deji
__________________________________________________________
Find your next car at http://autos.yahoo.ca
6:12 p.m.
On 12/17/05, Deji Akingunola <deji_aking(a)yahoo.ca> wrote:
Merely rebooting the system will cure your problem.
Deji
This problem was not fixed by a reboot. After the partial update there
was no libpam.so of any version.
I did say "I couldn't start up the computer in runlevel 3 or 5 any more".
n0dalus.
7:21 p.m.
On 12/16/05, n0dalus <n0dalus+redhat(a)gmail.com> wrote:
On 12/17/05, Deji Akingunola <deji_aking(a)yahoo.ca> wrote:
>
> Merely rebooting the system will cure your problem.
>
> Deji
>
This problem was not fixed by a reboot. After the partial update there
was no libpam.so of any version.
Well sounds like something went horribly wrong with that update.
Better try to to see if you can reproduce it.
Can't you reboot into runlevel 1 and bypass this? Or in rescue mode
off of an fedora installer image? If there is no libpam.so of any
version install then rpm -V pam should most definitely indicate a
problem.
pam-0.99.2.1-1 most certaintly has
/lib/libpam.so.0
/lib/libpam.so.0.81.1
in its payload.
And pam seems to update just fine for me. You'll have to do you best
to figure out why the libpam files didn't install.
-jef
8:27 p.m.
On 12/17/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
Can't you reboot into runlevel 1 and bypass this? Or in rescue mode
off of an fedora installer image? If there is no libpam.so of any
version install then rpm -V pam should most definitely indicate a
problem.
pam-0.99.2.1-1 most certaintly has
/lib/libpam.so.0
/lib/libpam.so.0.81.1
in its payload.
And pam seems to update just fine for me. You'll have to do you best
to figure out why the libpam files didn't install.
-jef
Yeah in my original mail I said that was the solution (runlevel 1 then
update again using pam rpms from yum's cache).
What log files should I be looking at to see what caused this? I had a
look at a few but didn't see anything really obviously wrong. I don't
know if there's a way to roll-back all the updates and try again
without a whole lot of work, and I don't even know if the problem
would show itself again with certainty.
I will have a look at the rpm.spec too because something like this
should really be an atomic operation. It shouldn't remove the old
libpam.so until it's sure the new libpam.so is properly installed.
n0dalus.
5:26 a.m.
On 12/17/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
And pam seems to update just fine for me. You'll have to do you
best
to figure out why the libpam files didn't install.
-jef
I have done some more looking into the problem, and while
unfortunately I was unable to reproduce the same problem, I did find
some things in the log files.
At the time of the update, lots of scriptlets failed with the
accompianing log message below:
Dec 17 08:53:26 kernel: audit(1134771806.214:1322): avc: denied {
transition } for pid=17748 comm="yum" name="bash" dev=hda7
ino=163054
scontext=root:system_r:ldconfig_t tcontext=root:system_r:rpm_script_t
tclass=process
I am pretty new to SELinux, but to me it seems that the scontext and
the tcontext are around the wrong way. I don't know how this could
happen. In policy.20, source rpm_script_t is allowed to run the
ldconfig_t process. What's happening here seems to be that ldconfig_t
is trying to run rpm_script_t (as far as SELinux is concerned), which
would not be what's really happening. I could be completely wrong
though, so hopefully someone more experienced in these matters can
comment.
I can reproduce this error message consistently when doing certain updates.
n0dalus.
9:38 a.m.
On Saturday 17 December 2005 06:26, n0dalus wrote:
On 12/17/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> And pam seems to update just fine for me. You'll have to do you best
> to figure out why the libpam files didn't install.
>
> -jef
I have done some more looking into the problem, and while
unfortunately I was unable to reproduce the same problem, I did find
some things in the log files.
At the time of the update, lots of scriptlets failed with the
accompianing log message below:
Dec 17 08:53:26 kernel: audit(1134771806.214:1322): avc: denied {
transition } for pid=17748 comm="yum" name="bash" dev=hda7
ino=163054
scontext=root:system_r:ldconfig_t tcontext=root:system_r:rpm_script_t
tclass=process
I am pretty new to SELinux, but to me it seems that the scontext and
the tcontext are around the wrong way. I don't know how this could
happen. In policy.20, source rpm_script_t is allowed to run the
ldconfig_t process. What's happening here seems to be that ldconfig_t
is trying to run rpm_script_t (as far as SELinux is concerned), which
would not be what's really happening. I could be completely wrong
though, so hopefully someone more experienced in these matters can
comment.
I can reproduce this error message consistently when doing certain updates.
I have exactly the same situation you have on a x86_64 install. I remember
that I batched the selinux and pam updates into a single yum update.
--
Gene
10:10 a.m.
New subject: Pam updates break system (Was: pam changes require dovecot restart)
n0dalus wrote:
On 12/17/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
>And pam seems to update just fine for me. You'll have to do you best
>to figure out why the libpam files didn't install.
>
>-jef
>
I have done some more looking into the problem, and while
unfortunately I was unable to reproduce the same problem, I did find
some things in the log files.
At the time of the update, lots of scriptlets failed with the
accompianing log message below:
Dec 17 08:53:26 kernel: audit(1134771806.214:1322): avc: denied {
transition } for pid=17748 comm="yum" name="bash" dev=hda7
ino=163054
scontext=root:system_r:ldconfig_t tcontext=root:system_r:rpm_script_t
tclass=process
I recently checked my system for duplicate rpms caused by scriptlet
failures and found quite a few ackages where the rpmdb was not cleaned
from the removed package on the post installation error due to SELinux
at the time of the problem. You might want to check your system for
duplicate entries in the database.
Another problem was preinstall scripts failing. The rpm would be
downloaded but not installed whenever yum was used or rpm directly to
install packages. Selinux-policy-targeted was one such package that
failed installation on the pre scripts.
Do you have the current version of selinux-policy-targeted? Or was it
locked at quite an earlier release?
I have selinux-policy-targeted-2.1.6-4 which exhibited the pam problem
with login denials. I was able to log into a terminal for both root and
user. The other errors with pam seemed to clear with a relabeling of the
system and booting into runlevel 5 with autologin in gdm.
I am pretty new to SELinux, but to me it seems that the scontext and
the tcontext are around the wrong way. I don't know how this could
happen. In policy.20, source rpm_script_t is allowed to run the
ldconfig_t process. What's happening here seems to be that ldconfig_t
is trying to run rpm_script_t (as far as SELinux is concerned), which
would not be what's really happening. I could be completely wrong
though, so hopefully someone more experienced in these matters can
comment.
I can reproduce this error message consistently when doing certain updates.
Check your entries in rpmdb for duplicates, remove just the db entry for
the old packages, reboot with selinux=0. Try to update your system via
yum or using cached packages in /var/cache/yum/development/packages.
Relabel your system for SELinux by using either touch /.autorelabel or
autorelabel via grub appending the entry during boot.
I have no idea personally about SELinux or the chicken or the egg
factors like scontext ...
Jim
n0dalus.
--
"In the fight between you and the world, back the world."
--Frank Zappa
10:37 a.m.
New subject: Pam updates break system (Was: pam changes require dovecot restart)
On Sat, 2005-12-17 at 11:10 -0500, Jim Cornette wrote:
I have selinux-policy-targeted-2.1.6-4 which exhibited the pam
problem
with login denials. I was able to log into a terminal for both root and
user. The other errors with pam seemed to clear with a relabeling of the
system and booting into runlevel 5 with autologin in gdm.
This also seems to fix the failures of the %pre and %post scriplets.
-train
1:53 a.m.
New subject: Pam updates break system (Was: pam changes require dovecot restart)
Herbert Rutledge wrote:
On Sat, 2005-12-17 at 11:10 -0500, Jim Cornette wrote:
>I have selinux-policy-targeted-2.1.6-4 which exhibited the pam problem
>with login denials. I was able to log into a terminal for both root and
>user. The other errors with pam seemed to clear with a relabeling of the
>system and booting into runlevel 5 with autologin in gdm.
This also seems to fix the failures of the %pre and %post scriplets.
-train
I hope this problem is fixed by the updated version. I cleaned my system
rpm database and updated to all that does not have dep issues. I would
hate to have to go through that sort of cleanup again, especially if
some major package became mangled, like pam.
Jim
--
Don't shoot until you're sure you both aren't on the same side.
6742
days inactive
6744
days old
10 comments
7 participants
participants (7)
-
Deji Akingunola -
Gene C. -
Herbert Rutledge -
Jef Spaleta -
Jim Cornette -
Michael A. Peters -
n0dalus