installpkg messing up perms
in [Slackware]
|
From: Robby Workman on 14 Jul 2010 18:09 On 2010-07-14, Henrik Carlqvist <Henrik.Carlqvist(a)deadspam.com> wrote: > > Speaking of umask, you might want to ask yourself why your ordinary user > account needs a more strict setting on umask (027 ?) than the important > root account (022 ?). There's plenty of good reason for that. It's certainly understandable that one would not want his own files world-readable by default. 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. -RW
From: Keith Keller on 14 Jul 2010 18:19 On 2010-07-14, Robby Workman <newsgroups(a)rlworkman.net> wrote: > > I'm sure there's a corner case out there somewhere, but I just do > not see a reason for *root* to have a umask other than 0022. Have you thought at all about Sylvain's suggestion to put an explicit umask in the SlackBuild scripts? I know it could be a lot of work, but it also seems like a good way to ensure a sane umask for building a package. Or, in the least amount of work case, would you consider modifying the howto as I suggested earlier, or otherwise mentioning needing the correct umask? > Maybe it is, or maybe it isn't, but it's STILL not a problem with the > scripts or pkgtools. In this case it seems like the OP's problem is PEBKAC. (I love that acronym!) --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: Dario Niedermann on 14 Jul 2010 18:25 Robby Workman <newsgroups(a)rlworkman.net> wrote: > The installpkg script isn't broken in this regard. The package was > broken. No one ever said the package wasn't broken. Obviously that's NOT the point. It's NEVER been the point. The point is, what should a well-written package installer do with a broken package? Should it happily mess permissions up on system directories as installpkg does? > The *real* solution is to not build a broken package Well, duh... -- > 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: Jim Diamond on 14 Jul 2010 19:00 On 2010-07-14 at 19:25 ADT, Dario Niedermann <M8R-cthw2f(a)spamherelots.com> wrote: > Robby Workman <newsgroups(a)rlworkman.net> wrote: >> The installpkg script isn't broken in this regard. The package was >> broken. > No one ever said the package wasn't broken. Obviously that's NOT the > point. It's NEVER been the point. > The point is, what should a well-written package installer do with a > broken package? Should it happily mess permissions up on system > directories as installpkg does? 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?) Is that the only case you would have it work for? Or do you think it is possible to anticipate every possible type of problem? 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? I'm seriously interested in your thoughts here. Please share. Cheers. Jim
From: Mike Jones on 14 Jul 2010 19:23
Responding to Keith Keller: > On 2010-07-14, Sylvain Robitaille <syl(a)alcor.concordia.ca> wrote: >> Keith Keller wrote: >> >>> In any case, if modifying the SlackBuild scripts is not an option, I >>> would then suggest modifying the howto to unambiguously recommend su >>> -, in order to try to prevent any issues with differing umasks. >> >> No, that still places a dependancy on the user's environment matching >> (at least those characteristics of) the developper's. It's not >> reasonable to expect that the system running the script is a stock >> Slackware system. The script should create the environment it needs, >> especially given that we're discussing here some fairly trivial >> parameters to setup, and some that are commonly not left stock. > > Well, I'm not in charge of slackbuilds, so I wanted to give an > alternative in the case where they did not want to (or could not) > implement your suggestion. I agree that yours is superior, but as I'm > not in a position to help I don't want to presume anything about their > capacity. Modifying the howto is (likely) literally five minutes and > requires no testing. > > If Robby asks, I hope you'll offer to help. :) > > --keith Making the "su -" stuff more prominant in HOWTWOs would indeed have improved my chances of paying attention to it earlier than I did. I tripped over it accidentally while looking for something else. D'oh! -- *=( http://www.thedailymash.co.uk/ *=( For all your UK news needs. |