rpm %post script fails returning 127

[Shintaro Fujiwara]

HI, during the process of #rpm -ivh my_program, I had an error saying as
follows.

In spec file, I wrote one line which runs a script.

Studying web, I found some guy had a same kind of trouble, and another guy
saying that update selinux-policy and it will fix the problem.

So, I updated as follows and still I have an error.

Fortunately or not, when I set enforce 0, it works fine (%post script
works).

But, it's embarassing, my program is for SELinux!

What's going on for rpm and please fix this.

Thanks for reading.

[root@localhost ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28
[root@localhost ~]# rpm -ivh --force
/home/fujiwara/rpmbuild/RPMS/i686/segatex-7.990-1.i686.rpm
Preparing...                          #################################
[100%]
Updating / installing...
   1:segatex-7.990-1                  #################################
[100%]
warning: %post(segatex-7.990-1.i686) scriptlet failed, exit status 127
[root@localhost ~]# rpm -qa|grep selinux
selinux-policy-devel-3.12.1-116.fc20.noarch
selinux-policy-3.12.1-117.fc20.noarch
mod_selinux-2.4.4-2.fc20.i686
libselinux-python-2.2.1-6.fc20.i686
libselinux-devel-2.2.1-6.fc20.i686
selinux-policy-mls-3.12.1-116.fc20.noarch
selinux-policy-targeted-3.12.1-116.fc20.noarch
libselinux-2.2.1-6.fc20.i686
selinux-policy-doc-3.12.1-116.fc20.noarch
libselinux-utils-2.2.1-6.fc20.i686
[root@localhost ~]#

[Dominick Grift]

On Sat, 2014-01-18 at 16:13 +0900, Shintaro Fujiwara wrote:
> HI, during the process of #rpm -ivh my_program, I had an error saying
> as follows.

Yes this was a major mess-up that affected many many fedora users. Some
of which got their system broken beyond repair (maybe because they lack
knowledge to repair it , i dont know)

I do not understand how this could have happened. Does this go to
Fedora-testing repository first? Does it not need karma first?

How could a change with such great impact make it into Fedora 20 in the
first place. This is not rawhide.

Anyways yes bad publicity for SELinux but then again, this is Fedora and
we (should) know that this can happen...

[Stephen Glenn]

I'm running a pretty standard Fedora-20 release.
What I did to work through the fixes on this:

## Clean up yum to start with.
  yum --enablerepo='*' clean all
  yum-complete-transaction --cleanup-only

## Set SE to permissive
  setenforce 0

## Find out what needs help
  yum check

## Manually update, remove, fix, etc...  PAIN.

## Then to correct any duplicates
  package-cleanup --dupes
  package-cleanup -y --cleandupes

## Get the system updates
  yum -y --skip-broken distro-sync

## Set SE back to enforcing
  setenforce 1
  yum check
  getenforce

... I hope this help others...

On Sat, Jan 18, 2014 at 11:56 AM, Dominick Grift
wrote:
> On Sat, 2014-01-18 at 16:13 +0900, Shintaro Fujiwara wrote:
> > HI, during the process of #rpm -ivh my_program, I had an error saying
> > as follows.
>
> Yes this was a major mess-up that affected many many fedora users. Some
> of which got their system broken beyond repair (maybe because they lack
> knowledge to repair it , i dont know)
>
> I do not understand how this could have happened. Does this go to
> Fedora-testing repository first? Does it not need karma first?
>
> How could a change with such great impact make it into Fedora 20 in the
> first place. This is not rawhide.
>
> Anyways yes bad publicity for SELinux but then again, this is Fedora and
> we (should) know that this can happen...
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Shintaro Fujiwara]

Hi, guys.

Thanks for your advices.

I updated selinux-related policies to 117.
Hope others could fix theirs, too...

2014/1/19 Stephen Glenn
> I'm running a pretty standard Fedora-20 release.
> What I did to work through the fixes on this:
>
> ## Clean up yum to start with.
>   yum --enablerepo='*' clean all
>   yum-complete-transaction --cleanup-only
>
> ## Set SE to permissive
>   setenforce 0
>
> ## Find out what needs help
>   yum check
>
> ## Manually update, remove, fix, etc...  PAIN.
>
> ## Then to correct any duplicates
>   package-cleanup --dupes
>   package-cleanup -y --cleandupes
>
> ## Get the system updates
>   yum -y --skip-broken distro-sync
>
> ## Set SE back to enforcing
>   setenforce 1
>   yum check
>   getenforce
>
> ... I hope this help others...
>
> On Sat, Jan 18, 2014 at 11:56 AM, Dominick Grift <[e-mail]
> > wrote:
> > On Sat, 2014-01-18 at 16:13 +0900, Shintaro Fujiwara wrote:
> > > HI, during the process of #rpm -ivh my_program, I had an error saying
> > > as follows.
> >
> > Yes this was a major mess-up that affected many many fedora users. Some
> > of which got their system broken beyond repair (maybe because they lack
> > knowledge to repair it , i dont know)
> >
> > I do not understand how this could have happened. Does this go to
> > Fedora-testing repository first? Does it not need karma first?
> >
> > How could a change with such great impact make it into Fedora 20 in the
> > first place. This is not rawhide.
> >
> > Anyways yes bad publicity for SELinux but then again, this is Fedora and
> > we (should) know that this can happen...
> >
> > --
> > selinux mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/selinux

[Miroslav Grepl]

On 01/18/2014 08:13 AM, Shintaro Fujiwara wrote:
> HI, during the process of #rpm -ivh my_program, I had an error saying 
> as follows.
>
> In spec file, I wrote one line which runs a script.
>
> Studying web, I found some guy had a same kind of trouble, and another 
> guy saying that update selinux-policy and it will fix the problem.
>
> So, I updated as follows and still I have an error.
>
> Fortunately or not, when I set enforce 0, it works fine (%post script 
> works).
>
> But, it's embarassing, my program is for SELinux!
>
> What's going on for rpm and please fix this.
>
> Thanks for reading.
>
> [root@localhost ~]# sestatus
> SELinux status:                 enabled
> SELinuxfs mount:                /sys/fs/selinux
> SELinux root directory:         /etc/selinux
> Loaded policy name:             targeted
> Current mode:                   enforcing
> Mode from config file:          enforcing
> Policy MLS status:              enabled
> Policy deny_unknown status:     allowed
> Max kernel policy version:      28
> [root@localhost ~]# rpm -ivh --force 
> /home/fujiwara/rpmbuild/RPMS/i686/segatex-7.990-1.i686.rpm
> Preparing... ################################# [100%]
> Updating / installing...
>    1:segatex-7.990-1 ################################# [100%]
> warning: %post(segatex-7.990-1.i686) scriptlet failed, exit status 127
> [root@localhost ~]# rpm -qa|grep selinux
> selinux-policy-devel-3.12.1-116.fc20.noarch
> selinux-policy-3.12.1-117.fc20.noarch
> mod_selinux-2.4.4-2.fc20.i686
> libselinux-python-2.2.1-6.fc20.i686
> libselinux-devel-2.2.1-6.fc20.i686
> selinux-policy-mls-3.12.1-116.fc20.noarch
> selinux-policy-targeted-3.12.1-116.fc20.noarch
> libselinux-2.2.1-6.fc20.i686
> selinux-policy-doc-3.12.1-116.fc20.noarch
> libselinux-utils-2.2.1-6.fc20.i686
> [root@localhost ~]#
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

There is a bug for this issue.

https://bugzilla.redhat.com/show_bug.cgi?id=1054350

where I apologized for this issue. Unfortunately it went (also thru 
updates-testing) so quickly and we catched this issue too late.

[Dominick Grift]

On Sun, 2014-01-19 at 20:45 +0100, Miroslav Grepl wrote:
> >
>
> There is a bug for this issue.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1054350
>
> where I apologized for this issue. Unfortunately it went (also thru
> updates-testing) so quickly and we catched this issue too late.

I do not know the details of this issue but looks to me like a bug in
RPM instead (excuse me if i am wrong).

One should be able to run RPM/RPM scripts without a domain/role
transition if one has appropriate permissions, and unconfined_t has
those AFAIK.

Looks like that karma procedure does not always fully work.

I might have made the same mistake if i were in your shoes.

Although i probably would be really careful with any changes not for
rawhide, and i would have probably tested the change locally first, but
that does not have to mean i would have caught this bug.

Anyways where people work, mistakes are made. Lesson learned.