installpkg messing up perms
in [Slackware]
|
From: Robby Workman on 19 Jul 2010 01:48 On 2010-07-15, Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: > Robby Workman wrote: > >> The root account is for *system* administration, so that premise is >> not valid at all; instead, the assumption should be that all files >> *are* world-readable, and exceptions are made on case-by-case basis. > > I've worked on systems where it made more sense to have root's umask be > 077, and treat anything else as exceptions. The only "assumption" that > should be made here, quite honestly, is that your scripts can't count on > the environment under which they run to match that which you consider > "correct", so they should explicitly set the environment components > which they need in order to properly function. On such a system, you will run into the same problems if you do a "plain" installation using ./configure ; make ; make install though, so I just don't think it's quite fair to blame the script. If an admin is installing system-wide software, and that admin has set a more-restrictive-than-default umask for root, then that admin should understand (or *will* understand) that the umask will temporarily need to be set to 0022. By the same token, an admin that has a restrictive umask for his user account should understand what parts of the environment do/do not get inherited depending on how one obtains root privileges. To be clear, the SlackBuilds.org admins are having a discussion about this, and we're considering all angles. I personally am leaning towards simply enhancing our documentation (as opposed to editing our scripots) due to the paragraph above. -RW
From: Mike Jones on 19 Jul 2010 05:44 Responding to Robby Workman: > On 2010-07-15, Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: >> Robby Workman wrote: >> >>> The root account is for *system* administration, so that premise is >>> not valid at all; instead, the assumption should be that all files >>> *are* world-readable, and exceptions are made on case-by-case basis. >> >> I've worked on systems where it made more sense to have root's umask be >> 077, and treat anything else as exceptions. The only "assumption" that >> should be made here, quite honestly, is that your scripts can't count >> on the environment under which they run to match that which you >> consider "correct", so they should explicitly set the environment >> components which they need in order to properly function. > > > On such a system, you will run into the same problems if you do a > "plain" installation using ./configure ; make ; make install though, so > I just don't think it's quite fair to blame the script. If an admin is > installing system-wide software, and that admin has set a > more-restrictive-than-default umask for root, then that admin should > understand (or *will* understand) that the umask will temporarily need > to be set to 0022. By the same token, an admin that has a restrictive > umask for his user account should understand what parts of the > environment do/do not get inherited depending on how one obtains root > privileges. > > To be clear, the SlackBuilds.org admins are having a discussion about > this, and we're considering all angles. I personally am leaning towards > simply enhancing our documentation (as opposed to editing our scripots) > due to the paragraph above. > > -RW As the only reson /I/ SNAFUed a few things was because I missed the (more important than it looks) "su -" bit, a few highlights might be useful for the budding admin\homeuser. -- *=( http://www.thedailymash.co.uk/ *=( For all your UK news needs.
From: Sylvain Robitaille on 19 Jul 2010 09:09 Robby Workman wrote: > On such a system, you will run into the same problems if you do a > "plain" installation using ./configure ; make ; make install though, > so I just don't think it's quite fair to blame the script. ... We're not talking about a "plain" installation here, though. We're talking about building packages, using what is to most of us "third party" supplied scripts to facilitate that process. I don't think there is a question of "blame" here, rather than one of ensuring robustness (that is to say that the script will perform as intended under the conditions being discussed). Look at it as a proposed enhancement, rather than "blame". -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------
From: Eef Hartman on 19 Jul 2010 13:21 Helmut Hullen <Helmut(a)hullen.de> wrote: > That would be a revolution. Not only in the slackware world, but in > other distributions' worlds too. They all (except gentoo - perhaps) use > the "tar -x ..." way for unpacking the packets. And "tar" can change > permissions and owners. Actually the "rpm" world uses a variety of cpio (a .rpm is a cpio archive with a header in front of it, see the workings of rpm2targz). But, of course, cpio being a backup/restore program too, it will have the same habit of setting permissions and owners when run as root. -- ****************************************************************** ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-27 82525 ** ******************************************************************
From: Eef Hartman on 19 Jul 2010 13:25
Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > 1. the simpler solution: installpkg knows a list of untouchable system > directories; these will never be extracted from the tarballs, only > their contents will; Won't work for a first install as aaa_base actually has to CREATE all those "untouchable" directories, even when already there! The name has been chosen so that IT will always be installed first. > 2. the more radical solution, which I favour: installpkg checks the > contents of the tar package, takes note of which items are existing > directories and does not extract those from the tarball (again, only > their contents are extracted). This ensures permissions on existing > directories are never touched by installpkg. But Pat will never change installpkg that way, so if you want that, go to another distribution! -- ****************************************************************** ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-27 82525 ** ****************************************************************** |