installpkg messing up perms
in [Slackware]
|
From: Helmut Hullen on 15 Jul 2010 02:11 Hallo, Michael, Du meintest am 14.07.10: >> On 2010-07-14, Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: [bullshit] > The problem is, I'm not longer sure if we're being revisited by old > posters under a new guise, or if they all naturally sound the same. Seems to be a new gunfighter kid in the town, none of the well known trolls and twits. Seems to be an austrian troll - but the country isn't relevant for quality. Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: Helmut Hullen on 15 Jul 2010 03:10 Hallo, Henrik, Du meintest am 15.07.10: >> 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. > With the above solution it will no longer be possible to easily > create packages that tightens up or loosens permissions on existing > directories. In your case it is exactly what you want now. Others who > need such packages can still create them, but it requires a little > more work as all permissions has to be changed from the script. It's (now) a completely other way, but it is possible too: a) using "tar -x ..." with a directory in the packet which has the desired rights and ownership: "tar" overwrites b) using the last step in "installpkg": sh install/doinst.sh with a command like mkdir -m 777 -p path/to/special/directory chown john:doe path/to/special/directory Most packets use the first way, and I like this way too. The second way may be better if there is some special user to create first. (I'm sure you know these two ways too, since many years ...) Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: Dario Niedermann on 15 Jul 2010 05:05 Henrik Carlqvist <Henrik.Carlqvist(a)deadspam.com> wrote: > 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; > > The above solution will break first time system installs. If your > installpkg never extracts the /usr or /etc directories, how will you > install Slackware on a clean disk? With such a solution you would probably > need some kind of --first-time-install flag to override your prefered > default behavior. That's why I favour the second solution: it's more general (even though it would be trivial to keep the current, unsafe behaviour as an option to be used in rare cases, such as a 1st time install). >> 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. > > With the above solution it will no longer be possible to easily create > packages that tightens up or loosens permissions on existing directories. Fact is, I don't think it's the job of the package installer to do this kind of housekeeping. It'd be simpler to use tar for the job, or even a very simple shell script. BTW, the script would have the advantage of being able to check if it's creating empty directories, as opposed to installpkg/tar, which couldn't. >> 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 installpkg will still not be fool proof. [...] No, but it would handle flawed packages more safely and gracefully. Also, builtin scripts should have to come as broken or malicious from the source in order to wreak havoc, they could hardly be unwittingly corrupted by the users. -- > 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 15 Jul 2010 06:06 Hallo, Dario, Du meintest am 15.07.10: >>> 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. [...] > BTW, the script would have the advantage of being able to check if > it's creating empty directories, as opposed to installpkg/tar, which > couldn't. That's no advantage, that is only an option. One of the differences between slackware and other distribution is: slackware's package management doesn't place the administrator under disability (in german: "entm�ndigt ihn nicht"). Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: Jim Diamond on 15 Jul 2010 11:16
On 2010-07-14 at 20:46 ADT, Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > Jim Diamond <Jim.Diamond(a)deleteme.AcadiaU.ca> wrote: > >> I'm really sort of curious here about what you think the installer >> should do. That is, how does it know that a package is broken? In >> your case, I guess it could have some logic that dictates what the >> permissions of some well-known system directories are, and not allow >> them to change as a result of installing a package. > > There are two solutions that I personally deem appropriate: > > 1. the simpler solution: installpkg knows a list of untouchable system > directories; these will never be extracted from the tarballs, only > their contents will; > > 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. > > In my implementation, installpkg will likely use 'tar tf' and 'sed' to > build a sanitized bill of materials, which will then be passed to tar > using the '-T' flag. 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. >> Also, while it would be possible to look at the tar file and peruse >> the directory permissions, Slackware packages can also have scripts. >> Do you think it is feasible to try to get the installer to examine >> every script to ensure a "broken" package won't cause problems? > 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. I agree that it could do what you suggest, but it isn't clear to me that your approach is the best. Of course, it doesn't really matter what I think, it is really what Pat V thinks that counts. (And, like almost any other program on a Linux system, anyone who doesn't like the way it works can change it to suit themselves.) Keep in mind that, while installpkg may or may not have a "formal specification", it is perfectly acceptable for a program's formal specification to say that a program's action on invalid input is undefined. In this case, if it is agreed that the package was broken, what installpkg did may have been perfectly acceptable according to its design. That doesn't mean it is broken. (Nor does it mean that what you want to happen is not an invalid suggestion as a possible feature for a new version of installpkg.) Cheers. Jim |