SlackBuild script environment (was Re: [12.2] installpkgmessing up perms)
in [Slackware]
|
Prev: sshfs, no directory count? was: ext4, truecrypt and sshfs, no d...
Next: SlackBuild script environment (was Re: [12.2] installpkg messing up perms)
From: Sylvain Robitaille on 15 Jul 2010 00:58 Robby Workman wrote: > I understand what you're staying, and part of me wants to agree, but > I can't help but argue ... You're certainly entitled to, but you should know going in that you won't convince me. I'm quite certain I'm right about this, even if things are the way they are for reasons that were agreed to be "good" according to the SlackBuilds.org script developers. > 1. Expecting root's umask to be 0022 and to have a sane PATH > is *not* unreasonable. It absolutely is unreasonable to impose such a dependancy when it is trivial to set it to what is required within the script itself. I'd even argue that it is arbitrary and your objection is intended to offer justification for what is really an oversight. > If you have changed root's umask, then you are (or soon will be) > very aware of various issues with that, and you need to take > appropriate steps to work around them. There have almost always been some systems I work on that purposely have a very restrictive umask for root. I go so far as to not hesitate to change root's shell (on most systems). Never, in my experience with either Linux (primarily Slackware, but not exclusively) or commercial Unixes have I encountered a situation where something breaks because I customized root's environment. (actually, that's not entirely true: I've had difficulty with some commercial software, especially from large, well known software vendors, that made assumptions about root's environment that weren't true even on the stock OS installation ...) > 2. How far should we go to ensure a sane root environment? > http://lists.slackbuilds.org/pipermail/slackbuilds-users/2010-July/006182.html You shouldn't be aiming to ensure a sane "root" environment, but rather you should be trying to ensure that the environment required for the script to build a proper package is available. What constitutes a "sane" root environment is up to each system administrator to determine for his/her own systems, not for some developer(s) to dictate. If someone using your scripts wants to modify his/her root environment such that running your script as root could result in "dangerous" outcome, they're going about it all wrong. What the poster from the message you reference above overlooked is that the person modifying root's environment in order to coerce your script into doing something unintentional already has root on the system, and they could just perform whatever action it is they're after. You shouldn't even assume that your slackbuild script is running with root privilege at all. With only few exceptions, while building a package, seeing as these scripts use an installation path under /tmp (or some other user-determined temp directory), the only thing that root privilege is really required for is setting ownerships of the files. Otherwise, most SlackBuild scripts don't actually *need* to be run as root, and sure enough, my own slackbuild template script uses the following to permit me to test building packages without needing to be root: chown -R `id -un`.`id -gn` . The test package won't have the correct ownership, but if it otherwise builds fine, I can re-run as root (in fact, as euid=0; I don't login as root) and the package that then gets built is good to go. > We use git for SCM, and the modification would be trivial to > script. I'm just not sure it's a slope we want to slide... I don't understand why you wouldn't want to make your scripts more fault tolerant. -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------
From: Sylvain Robitaille on 15 Jul 2010 01:15 Grant wrote: > Sure, could be improved, but SBo follow same rules as Slackware, that > root environment is known, and Robby W. confirms that. None of my Slackware systems have any components that have suffered because my root environment is not "stock", and it most certainly is not "known" to the scripts that ship with the OS. > In my view Slackware is a very good second distro, ... Too many people view it that way, in my opinion. Slackware is the distribution that got it right. Why wait to find that out? That said, SlackBuilds.org is not Slackware. It includes people who have contributed a lot to Slackware, but the two are not the same. Both parties, of course, should be aiming to make their scripts as robust as they possibly can, without making any assumptions about the environment in which they run. > Switching to real root to create packages? What is "real root"? At the OS level, you're operating with a numeric userid, plus potentially an additional "effective userid" which results in your having some permissions you might not otherwise have. If either your userid or your effective userid equals zero (notwithstanding SELinux and similar bastardizations of system security models), you have the privilege to perform pretty much any operation on any part of the system. That's "real root", and I can get it whether I login as root, or use "su" with or without the dash, or even just run an suid copy of a command shell. The script that creates the packages should not assume even that it has root privilege. In more cases than not, the only purpose for that privilege is so the ownership of the contents of the created tar file can be predictable. > I don't like it, but it's what slackware expects and is built on. I don't see where you get this impression. -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------
From: Sylvain Robitaille on 15 Jul 2010 10:25 Helmut Hullen wrote: > I've tried running "cmus.SlackBuild" ... under a non-root-account: > didn't work. "didn't work" is not a useful report. I haven't read that script so I don't know where it requires root privilege. Most require it only for the benefit of "chown", for which I've already posted the solution I use in my own scripts. -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------
From: Sylvain Robitaille on 15 Jul 2010 11:16 Helmut Hullen wrote: >>> I've tried running "cmus.SlackBuild" ... under a non-root-account: > ... > chown: changing ownership of `./some_file': Operation not permitted That's exactly consistent with what I've said in several messages. See another of my messages for how I make my own scripts not have this problem. > And "/tmp/SBo/package-cmus" is empty. No surprise. Most of these scripts that I've seen (and I've adopted the same in my own scripts) use "set -e" to abort immediately when an error is encountered. In this case, it will have aborted after the call to chown failed, so nothing gets configured, made, or installed. -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------
From: +Alan Hicks+ on 15 Jul 2010 14:47
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'll finally enter this discussion. :^) On 2010-07-13, Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: > I would like to argue that the scripts > should explicitly set any environment that they require to produce a > proper package. That should certainly include, at a minimum, the umask > the script expects to run with (and the PATH environment where any > commands used should be found). I think you have a valid point, at least for the umask. Setting PATH isn't necessarily a bad idea either. Both of these could be added to our template without causing any problems that I can foresee. With that said, I don't see us going back and changing working scripts because after several years of SBo one mental midgit experienced a failure caused by his lack of understanding and bitched about it. Hundreds or thousands of people have used SBo scripts over the past years and only this 1 person has ever complained of the problem. I just don't see a justification for editing a large volume of existing scripts for such a trivial and rare problem. - -- It is better to hear the rebuke of the wise, Than for a man to hear the song of fools. Ecclesiastes 7:5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkw/V8IACgkQDyaEVbMHxsYq6ACfS9Tc8sn2owtDdK0uUeP4x075 mPMAn21U3wcacQDVBzsZibsya722Hvai =FQyV -----END PGP SIGNATURE----- |