LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Harmful SBo Script? evolus-pencil corrupted my system... (http://www.linuxquestions.org/questions/slackware-14/harmful-sbo-script-evolus-pencil-corrupted-my-system-4175446825/)

astrogeek 01-22-2013 09:14 PM

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

Code:

sudo installpkg evolus-pencil-1.3-noarch-1_SBo.tgz |tee ~/install_notes/evolus-pencil_install
...to install it and... and immediately could do nothing else!

Using basic things like
Code:

ls
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...)

mlangdn 01-23-2013 01:42 AM

Nice work!

Alien Bob 01-23-2013 04:30 AM

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

Code:

tar tvf  /tmp/evolus-pencil-1.2-x86_64-2_SBo.tgz | less
drwxr-xr-x root/root        0 2013-01-23 11:25 ./
drwxr-xr-x root/root        0 2013-01-23 11:25 usr/
drwxr-xr-x root/root        0 2013-01-23 11:25 usr/bin/
-rwxr-xr-x root/root        82 2013-01-23 11:25 usr/bin/evoluspencil
drwxr-xr-x root/root        0 2013-01-23 11:25 usr/lib64/
drwxr-xr-x root/root        0 2013-01-23 11:25 usr/lib64/evolus-pencil-1.2/
drwxr-xr-x root/root        0 2010-06-04 06:54 usr/lib64/evolus-pencil-1.2/defaults/
drwxr-xr-x root/root        0 2010-06-04 06:54 usr/lib64/evolus-pencil-1.2/defaults/preferences/
...

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:
Code:

# umask
0022

Eric

astrogeek 01-23-2013 02:50 PM

Quote:

Originally Posted by Alien Bob (Post 4875987)
Astrogeek, does your root user have a non-standard umask?

No, that is fine for user and root:

Code:

[robert@peggysue:~]# umask
0022

[root@peggysue:~]# umask
0022

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:

Code:

[robert@deimos:~]# umask
0022

[root@deimos:~]# umask
0022

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

Code:

tar -tvzf evolus-pencil-1.3-noarch-1_SBo.tgz |grep 'usr/bin/'
drwxr--r-- root/root        0 2013-01-23 12:20 usr/bin/
-rwxr-xr-x root/root        84 2012-05-25 22:59 usr/bin/evoluspencil

tar -tvzf evolus-pencil-1.3-noarch-1_SBo.tgz |grep 'usr/lib/$'
drwxr--r-- root/root        0 2013-01-23 12:20 usr/lib/

tar -tvzf evolus-pencil-1.3-noarch-1_SBo.tgz |grep 'usr/share/$'
drwxr--r-- root/root        0 2013-01-23 12:20 usr/share/

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...
Code:

rpm2cpio < $CWD/$PRGNAM-$VERSION-$APPBUILD.noarch.rpm | cpio -imdv
Which results in the following under 12.1...

Code:

ls -l /tmp/SBo/package-evolus-pencil/
total 4
drwx------ 5 root root 4096 2013-01-23 13:17 usr/

ls -l /tmp/SBo/package-evolus-pencil/usr/
total 12
drwx------ 2 root root 4096 2013-01-23 13:17 bin
drwx------ 3 root root 4096 2013-01-23 13:17 lib
drwx------ 3 root root 4096 2013-01-23 13:17 share

But results in this under 14...

Code:

ls -l /tmp/SBo/package-evolus-pencil/
total 4
drwxr-xr-x 5 root root 4096 Jan 23 13:18 usr/

ls -l /tmp/SBo/package-evolus-pencil/usr/
total 12
drwxr-xr-x 2 root root 4096 Jan 23 13:18 bin/
drwxr-xr-x 3 root root 4096 Jan 23 13:18 lib/
drwxr-xr-x 3 root root 4096 Jan 23 13:18 share/

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!

allend 01-24-2013 12:27 AM

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

astrogeek 01-24-2013 12:58 AM

Quote:

Originally Posted by allend (Post 4876594)
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.

gnashley 01-24-2013 01:02 AM

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.

astrogeek 01-24-2013 01:10 AM

Quote:

Originally Posted by gnashley (Post 4876603)
Older versions of cpio had this problem with faulty perms on dirs.

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...

Code:

find . -type d |xargs chmod 755
... 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!

Alien Bob 01-24-2013 03:03 AM

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:
Code:

find . \
  \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \
  -exec chmod 755 {} \; -o \
  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
  -exec chmod 644 {} \;

but that command will not catch and fix a directory with missing executable bits either (faulty directory perms "744").

Eric

astrogeek 01-24-2013 04:19 AM

Quote:

Originally Posted by Alien Bob (Post 4876650)
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).

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!

ruario 06-20-2013 01:19 PM

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

Quote:

Originally Posted by astrogeek (Post 4876681)
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.

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.


All times are GMT -5. The time now is 04:56 PM.