LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
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-03-2010, 11:09 AM   #16
GazL
Senior Member
 
Registered: May 2008
Posts: 4,484
Blog Entries: 7

Rep: Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965

Not all slackbuild writers are the same. Some will be unaware that this could even happen, others (as Eric has demonstrated above) believe it's your responsibility to have the environment setup appropriately before you run the slackbuild script, and others will want to make their scripts fail-safe, or as fail-safe as is practical.

I disagree with Eric on this one. I don't believe it's acceptable for a package created from a slackbuild script to change the permissions on a fundamental system directory such as /usr when it is installed.

Whether that is avoided by explicitly setting the umask in the script, using "makepkg -c y", a "find $PKG -type d -chmod 755 {} +" or even a "test "$(umask)" != "0022" && exit " doesn't matter, but IMO a well written slackbuild should not build a package that will damage your system just because you had the wrong umask set when you ran it.

However, the onus is on oneself to realise that most slackbuild scripts are just quick and dirty automation aids and won't do a whole lot of sanity/error checking, so you need to exercise an appropriate amount of caution.
 
Old 05-03-2010, 11:30 AM   #17
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 841

Rep: Reputation: 165Reputation: 165
I agree with you Eric. There is no requirement that a SlackBuild writer try to compensate for root's short-sightedness or, perhaps more typically, root's lack of understanding. I think the latter is more often the case, as it was for this user and for me when I experienced this problem three years ago.

I had not noticed that you started setting the umask in your SlackBuild updates over the past few months, but I recall that you previously said you would consider it, and I applaud you for doing it.

GazL, I agree with you that it isn't acceptable for a SlackBuild script to change the permissions on a fundamental system directory. But Eric is still right that the SlackBuild writer isn't obligated to design his scripts to be safe.

Last edited by Z038; 05-03-2010 at 11:33 AM.
 
Old 05-03-2010, 12:15 PM   #18
GazL
Senior Member
 
Registered: May 2008
Posts: 4,484
Blog Entries: 7

Rep: Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965
Quote:
Originally Posted by Z038 View Post
But Eric is still right that the SlackBuild writer isn't obligated to design his scripts to be safe.
Absolutely. A SlackBuild writer isn't obigated to make their script available at-all, and they should be accepted in the spirit they're offered with no demands attached.

I'm just expressing what I believe is a good practice that's all.
 
Old 05-03-2010, 04:46 PM   #19
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
I hadn't realized this thread was still going on.

Quote:
Originally Posted by Alien Bob View Post
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.

I don't think it's fair to dismiss an administrators decision as short-sighted.

Does root having a umask that prevents others from reading root owned files? Obviously not if it is going to be applied to system wide applications and files needed by users, but for roots own files it just makes sense.

Slackbuilds go through and set permissions when they install, do they not? If that is the case, would it not make more sense to have them set useful permissions independent of the umask?

Just curious.

Quote:
Originally Posted by GazL View Post
I disagree with Eric on this one. I don't believe it's acceptable for a package created from a slackbuild script to change the permissions on a fundamental system directory such as /usr when it is installed.

Whether that is avoided by explicitly setting the umask in the script, using "makepkg -c y", a "find $PKG -type d -chmod 755 {} +" or even a "test "$(umask)" != "0022" && exit " doesn't matter, but IMO a well written slackbuild should not build a package that will damage your system just because you had the wrong umask set when you ran it.
I agree with this completely, except that a umask of 0022 is not necessarily 'wrong'.

Quote:
Originally Posted by Z038 View Post
I agree with you Eric. There is no requirement that a SlackBuild writer try to compensate for root's short-sightedness or, perhaps more typically, root's lack of understanding. I think the latter is more often the case, as it was for this user and for me when I experienced this problem three years ago.
I don't think it is shortsighted to expect that when installing new software your permissions will be reset on system directories, if you have a different umask to what is expected.

Of course there is no requirement for quality....but as most slackbuilds are quality it is expected in a way. I am sure not just any slackbuild gets uploaded to slackbuilds.org

I'm not at all attacking slackbuilds here, and don't mean to seem that way. I do think it is reasonable that slackbuilds should not reset permissions no matter the circamstance.

However Eric gave an explanation of why they do, and that is enough for me. No big issue really.
 
Old 05-03-2010, 05:00 PM   #20
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 6,693

Rep: Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018Reputation: 4018
Since nobody is able to get into the /root directory, except for root, there is no need at all to have another umask for root than 0022.

Just as root in Slackware should have bash as the default shell, (s)he should also have a 0022 umask value. This is what Slackware expects of root.

If not, then you must be prepared to be extra cautious with whatever you do on your system that affects non-root users.

Eric
 
Old 05-03-2010, 06:17 PM   #21
rg3
Member
 
Registered: Jul 2007
Distribution: Fedora
Posts: 527

Rep: Reputation: Disabled
I think the sane option is to have both things. Since I introduced the "umask 022" at the beginning of my slackbuild scripts I have realized that umask 022 is the most practical umask one can have for the root user. While I kept the system umask to 077, I set root's umask to 022 in its $HOME/.profile. Yet I have not removed the umask command from the slackbuild scripts, just in case I make a mistake one day.
 
Old 05-03-2010, 07:03 PM   #22
Josh000
Member
 
Registered: Aug 2009
Distribution: Slackware 13 64bit
Posts: 534

Original Poster
Rep: Reputation: 35
Setting the umask to 0077 for all users provides a bit of extra security. The only reason to have it as 022 is because slackbuilds need it to be that way, which is fine, but is not an argument against having the umask to 0077 in and of itself.
 
Old 05-03-2010, 07:11 PM   #23
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,366

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
What do you not understand? Having the *root* account with anything but umask 0022 is bad, not just with SlackBuilds. If you manually do `./configure; make; make install` with a non-0022 umask as root then none of your other users can access the executables. If you create a configuration file for something, it cannot be read by the app when launched by a user. Running *root* with anything but a 0022 umask is stupid and there is *no* additional security by doing so. Using 0077 as a *user* is perhaps a good idea -- but not as root.
 
Old 05-03-2010, 10:42 PM   #24
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 841

Rep: Reputation: 165Reputation: 165
Quote:
Originally Posted by Alien Bob View Post
Just as root in Slackware should have bash as the default shell, (s)he should also have a 0022 umask value. This is what Slackware expects of root.
Are these Slackware expectations you refer to documented somewhere? This would be valuable for all new Slackware users, I'm certain.
 
Old 05-03-2010, 11:03 PM   #25
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 841

Rep: Reputation: 165Reputation: 165
Quote:
Originally Posted by T3slider View Post
What do you not understand? Having the *root* account with anything but umask 0022 is bad, not just with SlackBuilds. If you manually do `./configure; make; make install` with a non-0022 umask as root then none of your other users can access the executables. If you create a configuration file for something, it cannot be read by the app when launched by a user. Running *root* with anything but a 0022 umask is stupid and there is *no* additional security by doing so. Using 0077 as a *user* is perhaps a good idea -- but not as root.
I think that's a bit harsh, and it's also not true that there is *no* additional security by running root with umask 0022. With a mask of 0022, *every* file root creates will be world-readable. There are some configuration files that should not be world-readable.

There's nothing wrong with running root with a umask other than 0022. You just have to understand the implications of doing so, and take actions to prevent problems, just like you have to understand the implications of creating certain config files readable by the world.
 
  


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 04:35 PM.

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