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.

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.

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.

I hadn't realized this thread was still going on.


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.

I agree with this completely, except that a umask of 0022 is not necessarily 'wrong'.

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.

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

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.

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.

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.

Are these Slackware expectations you refer to documented somewhere? This would be valuable for all new Slackware users, I'm certain.

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.