installpkg messing up perms
in [Slackware]
|
From: Sylvain Robitaille on 15 Jul 2010 01:36 Robby Workman wrote: > ... What I mean is "make sure you have a sane environment after > switching to root." I have such an environment. It may or may not agree with what you expect from a "sane" environment. Scripts that you publish for public use could likely benefit from not making the assumption that the user's environment will necessarily meet the conditions of what you consider a "sane" environment. > ... I just do not see a reason for *root* to have a umask other than > 0022. I could argue the same, depending on the system, for a root umask of 0027 or 0077. Neither would constitute a "not sane" environment. -- ---------------------------------------------------------------------- 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:41 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. -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------
From: Henrik Carlqvist on 15 Jul 2010 02:04 Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > There are two solutions that I personally deem appropriate: Thanks for sharing your ideas on how installpkg could be improved. > 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. Also, the hardest part with the solution above is to make up the list of directories that should be untouchable. > 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. > 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. IMHO it would still be a better solution to fix the few custom packages that you have which are broken than to add complexity to installpkg which only solves the problems of some broken packages. 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: Helmut Hullen on 15 Jul 2010 02:02 Hallo, Dario, Du meintest am 15.07.10: >> The installpkg script isn't broken in this regard. The package was >> broken. > No one ever said the package wasn't broken. I guessed that it was broken. I have tried "cmus" which you have mentioned as an example: no problems. I have asked you many times how you have run "<packet>.SlackBuild" - no answer. I have asked you for some example packets - no answer. > The point is, what should a well-written package installer do with a > broken package? It's the job of the human installer to check the packets. Not the job of a script. Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me".
From: Helmut Hullen on 15 Jul 2010 02:08
Hallo, Jim, Du meintest am 14.07.10: > 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. (And, in such a > case, should it install the package and keep the correct directory > perms, or should it refuse to install the package?) 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. Viele Gruesse Helmut "Ubuntu" - an African word, meaning "Slackware is too hard for me". |