LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-02-2010, 06:05 AM   #1
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Rep: Reputation: 35
A slackbuild killed my permissions!


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?
 
Old 05-02-2010, 06:13 AM   #2
rfernandez
Member
 
Registered: Mar 2010
Location: Brazil
Distribution: Slackware64
Posts: 264

Rep: Reputation: 41
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

Last edited by rfernandez; 05-02-2010 at 06:23 AM.
 
Old 05-02-2010, 06:37 AM   #3
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
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....
 
Old 05-02-2010, 07:49 AM   #4
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 6,725

Rep: Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093
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
 
Old 05-02-2010, 10:55 AM   #5
rg3
Member
 
Registered: Jul 2007
Distribution: Fedora
Posts: 527

Rep: Reputation: Disabled
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.
 
Old 05-02-2010, 11:13 AM   #6
GazL
Senior Member
 
Registered: May 2008
Posts: 4,519
Blog Entries: 9

Rep: Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003
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.
 
Old 05-02-2010, 03:32 PM   #7
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
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?
 
Old 05-02-2010, 03:46 PM   #8
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 6,725

Rep: Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093
Quote:
Originally Posted by Josh000 View Post
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.
Old 05-02-2010, 07:13 PM   #9
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
OK, thanks for explaining that Alien_Bob.

No harm done, and I learned something quite useful to know
 
Old 05-02-2010, 09:33 PM   #10
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 841

Rep: Reputation: 165Reputation: 165
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.

Last edited by Z038; 05-02-2010 at 09:41 PM.
 
Old 05-02-2010, 11:46 PM   #11
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,366

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
This is why I always run SlackBuilds with
Code:
$ su -c "umask 0022 && ./name.SlackBuild"
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.
Old 05-03-2010, 07:07 AM   #12
GazL
Senior Member
 
Registered: May 2008
Posts: 4,519
Blog Entries: 9

Rep: Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003Reputation: 2003
Quote:
Originally Posted by Z038 View Post
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.
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.

Last edited by GazL; 05-03-2010 at 07:09 AM.
 
Old 05-03-2010, 08:37 AM   #13
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 6,725

Rep: Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093
Quote:
Originally Posted by GazL View Post
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
 
Old 05-03-2010, 09:42 AM   #14
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 841

Rep: Reputation: 165Reputation: 165
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?
 
Old 05-03-2010, 09:57 AM   #15
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 6,725

Rep: Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093Reputation: 4093
Quote:
Originally Posted by Z038 View Post
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
*.SlackBuild SolitudeSensus Programming 3 07-18-2009 12:50 AM
SlackBuild Skype - no permissions silverbird Slackware 4 02-26-2009 04:30 AM
mandriva inst killed permissions on /home partition alabamaman Mandriva 1 09-29-2007 03:30 PM
find history of a job killed by "kernel: Out of Memory: Killed process" poulacou Linux - Server 3 09-20-2007 05:24 PM
slackbuild libdvdcss win32 codec; permissions issue cmk77 Slackware 4 08-03-2007 08:00 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 11:08 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration