Hi there, given that apparently quite some packages are affected by the inability to use chmod/chown/chgrp when building as nobody, maybe we should take a step back and see if we can come up with a better solution than "hack the makefile, the move the commands to a PostInstScript". The problem I see with that is that it requires quite some effort by the package maintainer, can be tedious to maintain: If a new upstream version changes anything in that regard, it required adapting the patch, and the PostInstScript; in the best case, the patch fails to apply to the new version and you fix it; in the worst case, you don't notice the change and your PostInstScript gets out of sync with what the package really wants to do with its chmod/chown commands... And from a purely subjective point of view, I also find it more "esthetic" if the user/group ownership and access flags for files and dirs is already set correctly in the .deb file, and does not have to be modified later on... ;)
So, maybe there is another way to resolve this. Ideally, we would like packages to "just work" out of the box. If we could somehow "automagically" fix this, it would remove one major blocker for making --b-a-n default. Here is one idea: Maybe we could insert our own custom chmod/chown scripts into the PATH used for building packages, with suid flag set, so that they can invoke the original chmod/chown with the appropriate rights. Of course that punches a hole into the "non-root" approach, but a relatively small one (as long as we don't do --b-a-n to prevent security holes, this is not a big issue, anyway). We could also try to avoid that hole by filtering the path arguments passed to our chmod/chown/chgroup commands, to only accepts paths inside the build dir (or even only in the install dir). For that, in turn, some care would have to be taken to make sure callers can't "punch out" by using clever combos of ".." and symlinks. That could be done by using "readlink -f PATH" on each of the paths passed to the chmod util before matching it against the /sw/src/fink.build/%n-%v-%r prefix (or whatever the build dir is set to). But maybe I am missing some major obstacle here... ? Bye, Max ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
