Bug 176406

I don't think this is a postgres issue.  The %post failures are happening for
several packages.  In particular, the only %post action that postgresql-libs has
at all is /sbin/ldconfig.  I'll bet that all the packages that are showing
problems are trying to run ldconfig, and that's what's failing.

What do you see if you try to run ldconfig manually?

It runs successfully:

# ldconfig && echo OK || echo BAD
OK


But you're right, there seems to be a general problem with rpm, seemingly all
scripts fail, not only those involving ldconfig:


# rpm -ihv postgresql-server-8.0.4-2.FC4.1.x86_64.rpm 
Preparing...                ########################################### [100%]
error: %pre(postgresql-server-8.0.4-2.FC4.1.x86_64) scriptlet failed, exit
status 255
error:   install: %pre scriptlet failed (2), skipping
postgresql-server-8.0.4-2.FC4.1

# rpm -qp --scripts postgresql-server-8.0.4-2.FC4.1.x86_64.rpm 
preinstall scriptlet (using /bin/sh):
groupadd -g 26 -o -r postgres >/dev/null 2>&1 || :
useradd -M -n -g postgres -o -r -d /var/lib/pgsql -s /bin/bash \
        -c "PostgreSQL Server" -u 26 postgres >/dev/null 2>&1 || :

# If we're upgrading from rh-postgresql, we have to repeat the above actions
# after rh-postgresql-server is uninstalled, because its postun script runs
# after our pre script ...
postinstall scriptlet (using /bin/sh):
chkconfig --add postgresql
/sbin/ldconfig
preuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ] ; then
        /sbin/service postgresql condstop >/dev/null 2>&1
        chkconfig --del postgresql
fi
postuninstall scriptlet (using /bin/sh):
/sbin/ldconfig 
if [ $1 -ge 1 ] ; then
        /sbin/service postgresql condrestart >/dev/null 2>&1 || :
fi
if [ $1 = 0 ] ; then
        userdel postgres >/dev/null 2>&1 || :
        groupdel postgres >/dev/null 2>&1 || : 
fi




Maybe this could be related: I've added the "tsflags=repackage" option to
yum.conf to get the RPM rollback functionality. So during all upgrades and
erases, RPM has been repackaging the installed packages.  But the scripts
currently fail regardless of repackage being used or not. Doing "rpm
--rebuilddb" doesn't help, either.

Should I change the component from postgresql to rpm?

Created attachment 122557 [details]
bzipped output from "strace -f rpm -iv postgresql-server-8.0.4-2.FC4.1.x86_64.rpm"

This is output from running "strace -f rpm -iv
postgresql-server-8.0.4-2.FC4.1.x86_64.rpm". It's over 600 kb, so it's
compressed with bzip2.

Use bzcat to view it. It may contain hints as to why the scriptlets fail.

Especially the following looks suspicious:

[pid  8668] open("/proc/self/attr/exec", O_RDWR) = 9
[pid  8668] write(9, "root:staff_r:rpm_script_t\0", 26) = -1 EINVAL (Invalid
argument)
[pid  8668] close(9)                    = 0
[pid  8668] exit_group(-1)              = ?


Seems that forked rpm instance does some SELinux related stuff before exec-ing
the shell that would execute the scriptlet which lies in /var/tmp/rpm-tmp.79370

Writing to /proc/self/attr/exec fails... What's the semantics of such operation?
Switching SELinux contexts?

Anyway, this is apparently rpm problem, so I'm changing the component.

Hard to tell if this is RPM or SELinux messing up.  Do you have SELinux in
enforcing mode, and if so does turning it off make a difference?  Also, at
this point it'd behoove you to mention the rpm and selinux-policy package
versions.

No, SELinux has been in permissive mode since the system installation.

Also, selinux doesn't log any errors to kernel log when I try to install postgresql.

rpm code does not open /proc/self/attr/exec, libselinux code does. Changing component.

What version of policy do you have installed?

Also what does id -Z show?

You are trying to install with the staff_r role for some reason which should not
happen in targetd policy.

strict, running in permissive mode.

SELinux packages have the following versions:
libselinux-1.23.10-2
libselinux-1.23.10-2
libselinux-devel-1.23.10-2
selinux-policy-strict-1.27.1-2.16
selinux-policy-strict-sources-1.27.1-2.16
selinux-policy-targeted-1.27.1-2.16

I do all work through SSH, but I'm put in the staff_r role when opening SSH session:

# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:staff_r:staff_t


That's strange, since /etc/selinux/strict/users/system.users has the root user
defined as:

user root roles { sysadm_r staff_r secadm_r system_r };

grep for sshd in /etc/selinux/strict/contexts/default_context.  This is how the
program decides what is the default contexts to run a login session as.

The program should not be failing in permissive mode.  I will check the
libselinux version to make sure it allows continues even on failure.  But in
strict policy you should newrole -r sysadm_r before running rpm.  If you were
running in enforcing mode rpm should fail to install.

Fixed in libselinux-1.23.11-1.1

Closing bugs in MODIFIED state from prior Fedora releases. If this bug persists
in a current Fedora release (such as Fedora Core 5 or later), please reopen and
set the version appropriately.