At least, that is what I think happened.

I was interested in trying out tilda, which needs the confuse libary, both of which are slackbuilds on slackbuilds.org

I built and installed confuse, and then went to build tilda but got some error I could not follow up on.

However after this, nothing as a normal user would work!

For some reason my libary directories, /lib64, /usr/lib64 and other key directories such as /usr/share and /usr/bin were set to have permissions 700

It took me a while to figure out what was causing the problem.

Can anyone confirm that the confuse slackbuild resets your permissions like this? Otherwise, what could have caused it?

Can someone please give me the correct permissions for those direcories? Is it safe to just do chmod -R 755 /usr and /lib64?

This happened after building and installing SBo confuse?

EDIT: I just looked at the SBo scripts for Tilda and Confuse, and everything seems ok. By any chance, you couldn't have predefined some variable as TMP, CWD, to be different from the default values?

As for the chmod -R 755 /{usr,usr/lib64}, I think it's not fully recommended, as it will change the directory and every file/subdirectory to this permission. Though it seems to be the default value, some files may require different permissions.

EDIT2: And the premissions for those directories, here, are indeed 755

OK, it was not the fault of those slackbuilds as such

I had set my umask to 077, and for some reason this caused the slackbuilds to set key directories to mode 700, although I have no idea why.

Resetting my umask to 022 and reinstalling the packages fixed everything.


I really don't understand why the slackbuilds would work in this way....apparently I can't have any umask other than 022 or it will affect system permissions....

Indeed. You run the SlackBuild scripts from http://slackbuilds.org/ as root, always, and Slackware's root user (in fact, every UNIX root user) must have his umask set to 022. If you fail do do this, you will make your non-root users very unhappy.

Eric

Normally I use my own slackbuilds, and that's precisely one of the things I always set. In my template and in all my personal slackbuilds, the command "umask 022" is present at the top, because the system umask is set to 077 for security reasons and this can be nasty with slackbuilds.

You could also use the makepkg option to reset permissions, but it's better in general to use umask 022 when building things and take the building result unmodified. After all, when building a package a given file could be given some special permissions and the makepkg option would break that.

I'm with rg3 on this one. Adding a umask statement to the top of a script will prevent this sort of problem, and takes so little effort that there's really no excuse not to.

That's good to know....but why are slackbuilds resetting the permissions at all?

Why would they not only set the permissions for the files they are actually installing?

The SlackBuilds are not resetting the permissions on your system directories. The issue is more delicate.

The SlackBuild script compiles your sources and installs the resulting binaries to a temporary location which the "makepkg" program uses to create the final package.
The stage where "make install" installs the binaries to the temporary location involves creating directories like usr/lib usr/bin and such, and those are getting the wrong permissions and in the end, they will be stored inside the package.

When you run "installpkg" on that package, the permissions of files and directories inside the package will be applied to the filesystem where they are now installed, thereby wrecking havoc.

Eric

1 members found this post helpful.

OK, thanks for explaining that Alien_Bob.

No harm done, and I learned something quite useful to know

I did something like what you did a few years ago. I was installing the slackbuild as root, but I had changed the umask for root some few days previously to 027. Here's the thread, in case you are interested. A number of people were highly offended by the subject line of my thread and they gave me a hard time about it, although it doesn't seem much different from yours.

http://www.linuxquestions.org/questi...system-564082/

There was a previous thread I had created about permission problems I experienced after installing a slackbuild. It was in this thread that I realized what I'd done wrong, that is, I'd changed the umask of root from 022 to 027. root should generally have a umask of 022.

http://www.linuxquestions.org/questi...denied-563972/

The writers of slackbuilds could protect novice users against this sort of thing. They could check the umask to ensure that it is appropriate before proceeding, and either terminate with a error message or ask the user for permission to temporarily change the umask during execution of the slackbuild. Of course, once you make this mistake of running a slackbuild with an unsuitable umask set, you never do it again, and a lesson learned the hard way tends to diminish complacency and enhance understanding.

This is why I always run SlackBuilds with
just in case. It should be noted that using su (not `su -`) does *not* initialize the environment for root and it *does* inherit the umask from whatever user you are running as -- this is obviously *not* desirable when using `su -c` to run SlackBuilds! That being said I prefer running it with `umask 0022` myself instead of having to make sure you include that line in every SlackBuild you create -- it is easy to forget and since SlackBuilds can come from a variety of sources it is better to put that responsibility on you.

1 members found this post helpful.

umask settings remain within the scope of the currently running process (and its sub-processes), so there's absolutely no reason why you need to worry about asking the user for permission to change a umask in a script because the change will only effect that script for the duration of that script, and as soon as the shell running that script ends, the change will be lost.

If a script requires a specific umask setting to function correctly, then it should set that umask. Not assuming anything about the environment you inherit is just good programming practice. However, as T3Slider pointed out, it's also good practice to protect yourself against SlackBuild writers.

The Slackware pkgtools set their umask to 022 btw... but if the package content already has messed-up permissions that won't help.

Eric

Eric, then doesn't it seem reasonable that the slackbuild writer take precaution to ensure that the package gets built with the right permissions by setting the umask in the slackbuild script?

No, if root decides that his umask should be something else than 0022 and therefore will prevent the proper use of new software for all non-root users, that is his right. But a SlackBuild is not required to try and compensate for root's short-sightedness.

You may have noticed that the SlackBuild updates I released in the past months, are in fact setting the umask to 0022 ... but that is my own choice.

Eric