On Tuesday February 10 2015 09:37:53 Brandon Allbery wrote: >I think someone did have this (try to) happen to them recently-ish. I also
I'm not saying it's impossible, but my home directory is mostly a skeleton anyway, with symlinks to where the important stuff is. As long as ~/Library isn't touched I'm fine (which "unixy" stuff is unlikely to do), but even that gets backed up frequently enough. I don't recall having seen this recently-ish issue discussed on a ML - or it was about a port that I found no interest in. >know people who had a Homebrew installation eat itself, because it does >everything as the logged-in user. Well, it's called Home Brew for a reason, eh? :) >> I take it there is no official way to define the permissions mask for a >> macports user that would allow an admin user full control over content >> owned by the macports user (but not the reverse)? > > >Not sure you can make extended ACLs propagate the right way. IIRC you'd have to use umask() somewhere in a tcl extension, and then also unpack source archives with the options to not restore permissions. And hope that the build and install processes don't set too many permissions of their own. I see another problem though. Suppose I set the macports user permissions to wide open (ugo+rwx), everything the non-privileged phases write to disk is likely to have those permissions, and if that includes the destroot step as I think, they'll make it into the final install. The same would apply when setting portdbpath to a volume that's mounted without permissions support, I guess. R. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
