Upgraded to pyGTK-2.10.5 using slakbuilds

mattydee · 10-26-2007, 07:49 PM

After I did this, my permissions were messed up.

They were 700 on folders:
/usr/bin
/usr/share
/usr/lib
/usr/include
/usr/doc

I had to change these back (chmod -R 755)... I don't even know if these are the proper permissions, and thinking I might have to reinstall Slackware.

Has anybody had this problem or know why I did?

rworkman · 10-26-2007, 08:17 PM

Show the output of this command, both as normal user and root:

Code:

umask

It's probably going to be 0077.

For your normal user account, this is fine.
For root, this is bad. One of the side effects is exactly what you see here.

Pratt · 10-26-2007, 10:11 PM

Wow! Sorry, but I'm going to hijack this thread just for a second. What if umask is 0022 for both root and the normal user?
What does this mean?

rworkman · 10-26-2007, 11:01 PM

Quote:

Originally Posted by Pratt

Wow! Sorry, but I'm going to hijack this thread just for a second. What if umask is 0022 for both root and the normal user?
What does this mean?

I'm not sure I understand the question. Are you asking: "What does this (the original poster's problem) mean if the umask is left as the default (0022)?" ?

I'll work off the assumption that this is indeed your question, but first, let's clarify what's going on if umask is something else. Basically, the umask(2) setting determines which permissions should be *removed* from newly created files and directories. For a directory, the possible permissions are 7777, so a umask of 0022 when creating a new directory would result in the permissions of 0755 on the directory.
When umask is set to 0077, this will remove all group and user permissions from newly created files and directories; in essence,

Code:

7777 - 0077 = 0700

you get a directory that's only readable, writable, and cd into-able by its owner.

When makepkg(8) creates a package, it does so by bundling the contents of the directory in which it's run into a tarball, then compressing that tarball with gzip. If root's umask was 0077, then you might get a directory listing that looks something like this before packaging:

Code:

drwxr----- root/root         0 2007-10-16 22:41 ./
drwxr----- root/root         0 2007-10-16 22:41 etc/
drwxr----- root/root         0 2007-10-16 22:41 etc/foo.conf.new
drwxr----- root/root         0 2007-10-16 22:41 install/
-rw-r----- root/root      1313 2007-10-16 22:41 install/doinst.sh
-rw-r----- root/root      1067 2007-10-16 22:41 install/slack-desc
drwxr----- root/root         0 2007-10-16 22:41 usr/
drwxr----- root/root         0 2007-10-16 22:41 usr/bin/
-rwxr----- root/root     13080 2007-10-16 22:41 usr/bin/foo
...

When makepkg(8) packages it up, those permissions are kept.
When installpkg(8) installs that package, guess what happens? ;-)

Anyway, if the umask(2) setting is not at fault, then either the app's Makefile sets incorrect permissions or the build script is doing something evil most likely. I doubt either of those is the case, but we'll see...

mattydee · 10-27-2007, 12:51 PM

Quote:

Originally Posted by rworkman

Show the output of this command, both as normal user and root:

Code:

umask

It's probably going to be 0077.

For your normal user account, this is fine.
For root, this is bad. One of the side effects is exactly what you see here.

It's 0022 for both.

mattydee · 10-27-2007, 12:53 PM

The only problem now is that there are so many things that need to be suid (in /usr/bin for example)... oi... what a pain

rworkman · 10-27-2007, 11:14 PM

mattydee:

First, you shouldn't have done a recursive chmod on the directories -- just a chmod on the directory itself was all you needed.

Second, just to verify - this: http://slackbuilds.org/repository/12.0/libraries/pygtk/ is what you were building, right? I've just done a test build on this, and I can't replicate your problem at all. Are you sure some other package couldn't have done it?

If you've got all of your custom packages saved somewhere, then try this (note that it's ugly code, but it should accomplish what we want here):

Code:

for i in *.tgz ; do 
  tar -tzvf $i | grep usr/$ | grep '---' ; 
done

mattydee · 10-29-2007, 12:55 PM

Quote:

Originally Posted by rworkman

mattydee:

First, you shouldn't have done a recursive chmod on the directories -- just a chmod on the directory itself was all you needed.

Second, just to verify - this: http://slackbuilds.org/repository/12.0/libraries/pygtk/ is what you were building, right? I've just done a test build on this, and I can't replicate your problem at all. Are you sure some other package couldn't have done it?

If you've got all of your custom packages saved somewhere, then try this (note that it's ugly code, but it should accomplish what we want here):

Code:

for i in *.tgz ; do 
  tar -tzvf $i | grep usr/$ | grep '---' ; 
done

I realize now it was foolish to do a chmod -R. Is there a way to work recursively on directories only?

The code didn't work for me. Anyways, I don't think it was another package since I lost access to /usr/bin and would have noticed this right away. I hadn't installed any package recently before that. I am looking at bash_history for clues...

rworkman · 10-29-2007, 01:54 PM

Quote:

Originally Posted by mattydee

I realize now it was foolish to do a chmod -R. Is there a way to work recursively on directories only?

Code:

find /usr -type d -exec chmod 0755 {} \;

However -- there may very well be directories underneath /usr that shouldn't have those permissions. This code is to simply serve as an example

Quote:

The code didn't work for me. Anyways, I don't think it was another package since I lost access to /usr/bin and would have noticed this right away. I hadn't installed any package recently before that. I am looking at bash_history for clues...

Look at the pygtk package manually to verify that it has incorrect permissions - I'm curious.

mattydee · 11-05-2007, 02:14 PM

I ended up reinstalling Slack12... something that I wanted to do anyways since I "upgraded" from current at the time, and never really did a clean install.

rworkman:
It seems that the perms in pygtk ar good... I'm not sure what happened, but something similar happened after I re-installed when I compiled + installed jasper using a slackbuild...

???

This time, I fixed it properly only changing the dir i had too.

weird...

rworkman · 11-05-2007, 03:47 PM

mattydee:

Please do the same verification on Jasper - if there is indeed a package with bad permissions when created from one of our build scripts, that's a *serious* bug that I want to fix immediately, if not sooner :-)

fcaraballo · 11-06-2007, 12:56 PM

mattydee:

I've tested that jasper slackbuild from SBo quite a bit

and haven't run across a permissions problem before. I would be interested in knowing what other programs you installed prior to jasper?

MagicMan

mattydee · 11-07-2007, 10:51 AM

Quote:

Originally Posted by rworkman

mattydee:

Please do the same verification on Jasper - if there is indeed a package with bad permissions when created from one of our build scripts, that's a *serious* bug that I want to fix immediately, if not sooner :-)

Sorry for the late reply.

The directories in my Jasper...Sbo.tgz package ended up with 700 perms:
usr
-bin
-doc
--jasper
-include
--jasper
-man
--man1
-lib

I don't know what I did wrong...

mattydee · 11-07-2007, 10:59 AM

Quote:

Originally Posted by MagicMan

mattydee:

I've tested that jasper slackbuild from SBo quite a bit

and haven't run across a permissions problem before. I would be interested in knowing what other programs you installed prior to jasper?

MagicMan

I don't remember exactly, but I needed Jasper for Digikam:
exiv2
libgphoto
libkdcraw
libexiv2
libkipi
sqlite

These were all compiled by myself and I used checkinstall.

Alien Bob · 11-07-2007, 11:05 AM

All of these packages - needed for digiKam - are available at http://www.slackware.com/~alien/slackbuilds/ (SlackBuilds too).

Eric