Op 12 sep 2010, om 09:33 heeft Max Horn het volgende geschreven: > 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).
I see your point, but I worry whether this doesn't actually make it worse. It's quite a huge security risk. But if we do go with it: I'd propose not to make it suid root, but to make it hold a list of files to change ownership or mode; then after the build is done; instead of running a chown -R root:admin as Daniel said... Op 12 sep 2010, om 10:10 heeft Daniel Macks het volgende geschreven: > Currently > (approximately), --b-a-n switches to fink-bld for InstallScript and > related actions, then 'chown -R root:admin $builddir' so that it is > back to the normal state for live filesystem files. If we have chown'ed > files to (for example) games, that would wipe the ownership anyway. ... Just do a chown -R root:admin, *then* apply the changes in the list, and you will have a guarantee that things are fine. Something to watch for, though: If the new `chown` and `chmod` wrappers do an extensive check of the path to modify, then this check needs to be done just before making the actual change too, or there will be race conditions. But either way, I think having potential security risks is worse than having potential weird installation issues in the PostInstScript... How does Debian solve this problem? They have non-root build machines, right? Sjors
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ 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
