installpkg messing up perms
in [Slackware]
|
From: Jim Diamond on 16 Jul 2010 10:40 On 2010-07-15 at 13:26 ADT, Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > Jim Diamond <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote: >> As others have pointed out, this would make it more difficult for >> packages to modify directory perms when there is a valid reason to do >> so. It is not clear to me that this is a win-win. > The package installer should never alter permissions on pre-existing > directories, because this could break software that's already installed > and working. And it could also fix software that isn't working correctly. > Just think of the trainwreck it could potentially cause on a > production system. People who install untested software, or who do installations on production systems without testing them on test systems first, generally deserve what they get (or get what they deserve). I think you need to wrap your mind around the fact that just because *you* think "installpkg" is the place to catch (alleged) errors in packages, that is just one opinion of where the error checking should occur. There are examples of situations in which the current behaviour of installpkg is a good thing, so changing it to do what you want is not universally a good thing. In other words, applying a "bug fix" in the wrong place can cause other bugs to occur, and that isn't the way to maintain a robust system. >>> Scripts are a whole different issue. I don't think there's a realistic >>> way for the package installer to ensure they won't wreak havoc. >> So really there is no way for installpkg to guard against broken >> packages, in general. > Scripts should have to be designed (or mis-designed) to cause damage, > though. Just like the tar file has to be "mis-designed" (ok, "mis-created") to cause damage. > Which wouldn't be likely if you get them from a reputable source. Well, maybe, maybe not. I think most people consider the slackbuilds web site a reputable source, but the one valid thing you have pointed out is that the slackbuilds there make an incorrect assumption about root's environment. Hopefully this discussion will convince people contributing slackbuilds to write their scripts to be a bit more robust against local modifications of root's environment by the person administering that system. I suspect most of the slackbuilds at slackbuilds.org were taken from the basic idea of Pat V's slackbuilds. In Pat's case, he (apparently or presumably) doesn't modify root's umask, so his slackbuilds don't need a umask statement. But I think the slackbuilds at slackbuilds.org which are designed for people to run on their own machines need to be more robust than the ones Pat V uses. Cheers. Jim
From: Dario Niedermann on 16 Jul 2010 11:40 Jim Diamond <Jim.Diamond(a)deletehis.AcadiaU.ca> wrote: > And it could also fix software that isn't working correctly. And it could also break software that is working correctly... > I think you need to wrap your mind around the fact that just because > *you* think "installpkg" is the place to catch (alleged) errors in > packages, that is just one opinion of where the error checking should > occur. Whether you like it or not, installpkg *is* the *last* link where a flawed package - and that of course means flawed _unbeknownst_ to you - can be prevented from causing damage. If you don't stop it at the installer's level, you don't stop it at all. > There are examples of situations in which the current behaviour of > installpkg is a good thing They are exceptional/rare situations where the current, unsafe behaviour could be invoked as an option. -- > head -n1 /etc/*-{version,release} && uname -moprs Slackware 12.2.0 Linux 2.6.27.31-smp i686 AMD Turion(tm) 64 Mobile Technology MK-36 GNU/Linux
From: Helmut Hullen on 16 Jul 2010 12:32 Hallo, Dario, Du meintest am 16.07.10: >> And it could also fix software that isn't working correctly. > And it could also break software that is working correctly... Rubbish. When you install software you change the system. Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: Dario Niedermann on 16 Jul 2010 13:51 Helmut Hullen <Helmut(a)Hullen.de> wrote: > Rubbish. When you install software you change the system. Yeah, and if you use installpkg you'll change it more than you expect. -- > head -n1 /etc/*-{version,release} && uname -moprs Slackware 12.2.0 Linux 2.6.27.31-smp i686 AMD Turion(tm) 64 Mobile Technology MK-36 GNU/Linux
From: Eef Hartman on 16 Jul 2010 16:03
Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > If the packages are "broken" (i.e. for whatever reason they contain > system directories with non-sane permissions) installpkg should IN MY Yeah, but WHAT is a non-sane permission, that is the crux. You would need something like (openSUSE's) /etc/permissions database: -rw-r--r-- 1 root root 9772 2008-12-03 06:02 /etc/permissions -rw-r--r-- 1 root root 20853 2008-12-03 06:02 /etc/permissions.easy -rw-r--r-- 1 root root 1353 2008-12-03 06:02 /etc/permissions.local -rw-r--r-- 1 root root 22091 2008-12-03 06:02 /etc/permissions.paranoid -rw-r--r-- 1 root root 23767 2008-12-03 06:02 /etc/permissions.secure /etc/permissions.d: total 24 -rw-r--r-- 1 root root 65 2007-05-24 11:58 mail-server -rw-r--r-- 1 root root 65 2007-05-24 11:58 mail-server.paranoid -rw-r--r-- 1 root root 1756 2008-12-03 09:12 postfix -rw-r--r-- 1 root root 126 2008-12-03 09:12 postfix.paranoid -rw-r--r-- 1 root root 599 2010-05-03 18:39 texlive -rw-r--r-- 1 root root 599 2010-05-03 18:39 texlive.paranoid for installpkg to know which dir/file should have WHAT permission. I.E. the "normal" permission for /etc is 755 (rwxr-xr-x if you're not familiar with the numeric notation), but /etc/ssl/private should be 700 (NON-accessable for anyone else but root) and /var/tmp should be 1777 as everyone must be able to write in there. And there are lots more permissions that are "non-standard" in the whole system tree. You'll see that even the openSUSE scheme, above, gives the choice between several different attribute lists (the ones without a . in the name are the really-used ones, the ones WITH are the default "schemes" you can use, but you can make your own one, if you want to, maybe starting from one of those). The ones in the permissions.d are for installing specific packages. And insights change, so what used to be normal for "older" installations, could have to be changed FOR a specific package (/var/spool/* comes to mind, permissions there have a tendency to change dependant on the specific packages you install) or a newer "standard". So installpkg does need the right to do it "different" from what you thought it would do. Even the 1777 permission for /tmp and /var/tmp didn't come until the implementation of a specific "meaning" for the setuid bit for directories (/tmp used to be 777 before that). -- ****************************************************************** ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-27 82525 ** ****************************************************************** |