installpkg messing up perms
in [Slackware]
|
From: Henrik Carlqvist on 15 Jul 2010 17:52 Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > The package installer should never alter permissions on pre-existing > directories, because this could break software that's already installed > and working. Just think of the trainwreck it could potentially cause on > a production system. Think of the following scenario: In year 2017 Slackware 18.3 is relaeased. The package aaa_base contains the /etc directory with chmod 777. A day after the release someone realizes the mistake and creates a correction package which is distributed as patches/aaa_base-18.3.0-noarch-2.tgz Slackware users all over the world keeping their systems up to date with the latest patches get their security hole in /etc fixed, but a few users running a custom "safe" installpkg still have the security hole on their machines even though the patch package has been installed. Is it really so that a package installer never should alter the permissions on any pre-existing directory? regards Henrik -- The address in the header is only to prevent spam. My real address is: hc3(at)poolhem.se Examples of addresses which go to spammers: root(a)localhost postmaster(a)localhost
From: Dario Niedermann on 15 Jul 2010 18:05 Henrik Carlqvist <Henrik.Carlqvist(a)deadspam.com> wrote: > Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: >> The package installer should never alter permissions on pre-existing >> directories, because this could break software that's already installed >> and working. Just think of the trainwreck it could potentially cause on >> a production system. > > Think of the following scenario: > > In year 2017 Slackware 18.3 is relaeased. The package aaa_base contains > the /etc directory with chmod 777. A day after the release someone > realizes the mistake and creates a correction package which is distributed > as patches/aaa_base-18.3.0-noarch-2.tgz > > Slackware users all over the world keeping their systems up to date with > the latest patches get their security hole in /etc fixed, but a few users > running a custom "safe" installpkg still have the security hole on their > machines even though the patch package has been installed. > > Is it really so that a package installer never should alter the > permissions on any pre-existing directory? IMO yes, because any permission change done by installpkg is effectively being done "behind the admin's back". This method of changing existing settings without root's knowledge is guaranteed to cause trouble, sooner or later. I think the correction should be done by a script, consciously run by root. -- > 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: Mike Jones on 15 Jul 2010 18:46 Responding to Jerry Peters: [...] > I've been using Slackware since roughly it's inception. One of the > reasons I stick with it *because* the package manager is not > intelligent. I've used allegedly intelligent package managers, they're > just a PITA. Side comment: I've been playing with my new digital camera, and have come to the conclusion the "intelligent auto" setting is pretty dumb, and screws up more than it avoids by using low shutter speeds to get "ambient lighting", resulting in induced blur at lower shutter speeds than would be sane in a "Hit the iA button and snap it now!" situation. Because of this, I've set the thing on sports mode where it favours higher shutter speeds and relies on appropriate flash control instead. As a result, I am now getting nice sharp "snaps". Conclusion? There is no such thing as "artificial intelligence", only built-in incompetance. Is there a Slackware flash-OS avaliable for Panasonic cameras BTW? ;) -- *=( http://www.thedailymash.co.uk/ *=( For all your UK news needs.
From: Henrik Carlqvist on 16 Jul 2010 02:18 Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > IMO yes, because any permission change done by installpkg is effectively > being done "behind the admin's back". This method of changing existing > settings without root's knowledge is guaranteed to cause trouble, sooner > or later. > > I think the correction should be done by a script, consciously run by > root. But what if you like me would have about 50 Slackware machines to maintain? Would you still prefer to manually ssh into each and every machine to run scripts to alter such settings? Or would you like me on every machine add a file to /etc/cron.daily which checks if there are any new updates to install as packages and if so simply install them (however in this case not with installpkg but "upgradepkg --install-new")? Slackware packages is really a convenient way not only to install different software packages, but also to distribute different configurations. Once before a planned power blackout I even created and distributed a package which shut all machines down in a controlled way before the blackout. For me Slackware packages is not a way to install software. Instead I use slackware packages to distribute software, distribute custom configurations and distribute system changes. I usually also distribute new kernels to all machines using Slackware packages when there is need to install some patch in the kernel. Mostly to install software for testing I instead use "./configure; make; make install". If the software is good enough to be distributed to all machines I create a Slackware package with checkinstall, makepkg or makepack. Yes, sometimes I also use slackbuild scripts to create packages. The kind of fix that you are looking for in installpkg is already a part of makepkg. When creating a package with makepkg you are asked if directory permissions and file ownership should be set to sane values. At this question you still have the option to answer no if you know what you are doing and really want some odd permissions or ownerships in the created package. The easiest way for you to patch installpkg might be to let installpkg untar the package to a temporary directory, then run makepkg to create a new temporary and sane package and finally instead install the temporary package. However, even though this is easy to implement and solves your problem with broken packages most people would not like such a solution as there are cases when packages really should alter permissions on existing directories. regards Henrik -- The address in the header is only to prevent spam. My real address is: hc3(at)poolhem.se Examples of addresses which go to spammers: root(a)localhost postmaster(a)localhost
From: Dario Niedermann on 16 Jul 2010 07:47
Henrik Carlqvist <Henrik.Carlqvist(a)deadspam.com> wrote: > For me Slackware packages is not a way to install software. Instead I > use slackware packages to distribute software, distribute custom > configurations and distribute system changes. I usually also > distribute new kernels to all machines using Slackware packages when > there is need to install some patch in the kernel. I see your point and, as I said, it would be trivial to keep the current unsafe behaviour as an option. The admin should consciously consent (by using some command line flag) to have settings altered. I still think there's potential for disaster, but that's OK, as long as it's not being done without root's knowledge and explicit allowance. -- > 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 |