Harmful SBo Script? evolus-pencil corrupted my system...
 

I have not identified a specific cause of my problem yet and would ask anyone more qualified to have a look. Here is what happened:

On a Slackware 12.1 system I decided to try an application evolus-pencil using the current SW 14 SBo script to build the package.

The script repackages the binary from a noarch.rpm. The MD5 was good, no errors making the package.

I then used

...to install it and... and immediately could do nothing else!

Using basic things like resulted in a bash error message.

I found that the /usr directory permissions had changed to 744, as well as /usr/lib, /usr/bin and /usr/share!

Fearing a corrupted hard drive I first backed up anything of value then probed around my other partitions. Eventually I rebooted into a Slackware 14 installation on another partition of the same drive - all OK.

It turned out that the directory permissions listed above seemed to have been the only notable changes (fortunately it was not a recursive change!).

Nothing in the logs that caught my attention... I cannot see anything in the Slackbuild or doinst.sh that would cause this. The /usr paths from the noarch.rpm are in fact 744, but I would not expect that to result in such a critical change on my system!

Anyway, I reset the /usr, /usr/lib and /usr/bin directories to 755 and booted back into my slackware 12.1 partition... and uninstalled evolus-pencil! All seems OK but I am still looking into what might have happened and am fearful of other changes.

If anyone with a little time on their hands and a good eye for build scripts would take a look at the SBo script and resulting package, it might save someone else some heartache!

EDIT - I have xulrunner-1.9.1.7 installed - a dependency of evolus-pencil

EDIT #2 - I will write the maintainer, but would like to know there is actually a problem with the script and be able to describe it before shouting "Your script is broken"! It might just be the phase of the moon...

EDIT #3 - I rebuilt and reinstalled and it is definitely the installation that canges those permissions

EDIT #4 - OK, modifying the Slackbuild to set permissions on the extracted rpm tree before building the package makes it install correctly (wrt permissions). I did not think that installpkg changed parent directory permissions - but obviously not correct.

So, the SBo script will corrupt the system as it exists - I'll write the maintainer...

(After all of that it did not work due to too old xulrunner, and I am not up to rebuilding that tonight...)

Nice work!

I built this package on Slackware 13.37 just to check what happens and I do not see anything wrong with that package:

The permissions of the toplevel directories in the package seem perfectly fine.
I don't have a Slackware 14 computer where I can check the version 1.3 SlackBuild so there still is a possibility that this directory permissions issue was introduced later.

Astrogeek, does your root user have a non-standard umask? This is the default for Slackware's root account and SlackBuild scripts expect that this is not changed:
Eric

No, that is fine for user and root:

Today I have a Slackware 14 machine available so I built the package there and found that it works fine. So it results from some difference in my 12.1 machine and my 14 machine. Here is what I have found so far...

For completeness here is umask from that machine:

These are the permissions from the package on the 12.1 machine...

But they are all 755 when built on the 14 machine (same script and rpm package).

So I looked at how the script builds the package and I get all the way back to this line...
Which results in the following under 12.1...

But results in this under 14...

Which would seem to be the crucial difference.

I am not a cpio expert but the flags look OK to me.

For what it is worth, I long ago upgraded tar to 1.26 on the 12.1 machine, using the distribution slackbuild (retaining tar-1.13 for the package manager), no problems ever noted. But that does not appear to be in play at this point in any case.

So, there seems to be some difference in behavior of either rpm2cpio or cpio itself between the two machines.

I am unsure where to look from here, but will research cpio versions a little bit to further my education. Help from tutors always appreciated!

Try clearing the contents of /var/lib/rpm on the 12.1 install.

Thanks for the response allend.

I was surprised to find anything there as I know that I have never installed anything from rpms on this machine (although obviously some slackbuilds might have used rpm2cpio in the past).

So I tried your advice - sorry, same result 700 permissions on all directories from rpm2cpio.

I have in fact worked with it through the day and have found that it is definitely rpm2cpio which is the origin of the bad permissions. Whether that is an error or a version difference I have not been able to determine.

Older versions of cpio had this problem with faulty perms on dirs. I didn't know about rpmcpio having them...
Try using src2pkg to convert rpm packages -it does a thorough check and correction of perms. It probably has less to do in this case, as it uses other tools besides rpm2cpio/cpio for unpacking rpms.

Now THAT is an interesting bit of knowledge that I have not heard or seen anywhere else! Would you be able to point to any other source for more about that? You say it with such certainty that I do not doubt you have encountered it in some way.

FWIW - I have now 'fixed' the Slackbuild by adding this line after the rpm2cpio extraction...

... after which I built, installed and am now running evolus-pencil (after also updating xulrunner).

So it is no longer a "problem" for me, but it has certainly had my curiosity captive for the past day!

The evolus-pencil.SlackBuild script uses a "chmod" command which is inadequate and does not catch the directories which do not have the executable bit set (that executable bit is required for accessing that directory).
The script's chmod command is "chmod -R u+w,go+r-w,a-s .". On the other hand, my own (i.e. non-SBo) SlackBuild scripts use "chmod -R u+w,go+r-w,a+X-s .", the "a+X" will set the executable bit for directories which are missing it.
Slackware's own scripts have something more convoluted:
but that command will not catch and fix a directory with missing executable bits either (faulty directory perms "744").

Eric

You have given me the right word, "inadequate"... in my mind, such as it is, I have been conflicted on whether to call this an error, a bug, a mistake, or just one of those things.

But the truth is just that - the chmod command is inadequate for my particular circumstance, whatever the cause of those bad perms.

See earlier posts (#8 I think) - I "fixed" it for my own use by initially adding a find command to fix the permissions (but later used a+X same as you have indicated.)

I am still curious why my 12.1 rpm2cpio returns with the bad perms and later versions do not... but probably not worth much more effort to figure out.

So I consider the thread SOLVED and hopefully this discussion will suffice for others having a similar problem - it has been an education for me!

Thanks Eric!

I know this is an old thread but just to answer the following:

It is not (and indeed could not be) a problem with rpm2cpio, since rpm2cpio itself does not extract individual files and directories. All rpm2cpio does is strip the rpm header from the front of a cpio archive and decompress it. Extraction of the actual cpio contents is done by the cpio command itself. Your bug is almost certainly this one, which was fixed in GNU cpio version 2.9. However Slackware 12.1 only includes GNU cpio version 2.5.