On some platforms, including OS X, and probably more BSDs, the chown and chgrp commands, when called on a symlink, operate on the original files by default instead of the links. When ebuild.sh checks to see if any files have an owner or group of portage, if it finds a link, it thus changes the owner/group of the original file. This is a Bad Thing because: - the original file might not supposed to be owned by root:wheel - if the original file was setuid or setgid, it'll loose the setuid/setgid bits when its owner/group are changed - if the symlink is absolute, the chown/chgrp will cause a sandbox violation (bug 94199, back from the dead again!) The solution: either pass the -h option to chgrp and chown, which tells it not to dereference symlinks, or to not call chown or chgrp on symlinks at all, or do something I didn't think of. (I'm filing this as a separate bug from bug 94199 because, though chowning and chgrping these symlinks on OSX/BSD could, in some cases, cause sandbox violations, that is just one of the possible things that could go wrong and, even then, only in certain cases (symlinks with absolute paths).)
Created attachment 63847 [details] Test case 1 This is an ebuild for a package with two files: /usr/share/bug99616test/foo (owned by daemon:daemon) and /usr/bin/bug99616test, which confirms that the former is owned by daemon:daemon.
Created attachment 63848 [details] Test Case 2 This is an ebuild for a package with three files: /usr/share/bug99616test/foo (owned by daemon:daemon) /usr/share/bug99616test/bar, a symlink owned by portage:portage pointing to "foo" /usr/bin/bug99616test, which confirms that the former is owned by daemon:daemon. When installed on Linux (i.e. GNU userland), ebuild.sh's chown and chgrp should modify bar, and running bug99616test reports that foo is still owned by daemon:daemon. However, on OS X (BSD userland), ebuild.sh's chown and chgrp should modify foo; bug99616test reports that foo isn't owned by daemon:daemon.
Created attachment 63849 [details] Test Case 3 This is an ebuild for a package with four files: /usr/share/bug99616test/foo (owned by daemon:daemon) /usr/share/bug99616test/bar, a symlink owned by portage:portage pointing to "foo" /usr/share/bug99616test/baz, a symlink owned by portage:portage pointing to "/usr/share/bug99616test/foo" /usr/bin/bug99616test, which confirms that the foo is owned by daemon:daemon. When installed on Linux (i.e. GNU userland), ebuild.sh's chown and chgrp should modify bar and baz, and running bug99616test reports that foo is still owned by daemon:daemon. However, on OS X (BSD userland), ebuild.sh's chown and chgrp should modify foo (when trying to modify bar) and should then cause a sandbox error when trying to modify baz.
Flameeyes, sending your way. I remember a similar bug, maybe even posted by you, but cannot find it.
Moving to dev-portage, cc: bsd@g.o and osx@g.o.
*** This bug has been marked as a duplicate of 94199 ***
This bug is not a duplicate of bug 94199. 94199 is about sandbox violations caused by ebuild.sh's chmod'ing symlinks with absolute paths. This bug is about multiple problems (including but not limited to sandbox violations) caused by ebuild.sh's chown'ing and chgrp'ing symlinks on a BSD-ish userland. The two bugs are similar, and even related, but not the same.
Bug 94199 describes one symptom of the issue. This bug describes another symptom. The issue is still the same. The other bug contains the fix. The fix is released in a stable portage. *** This bug has been marked as a duplicate of 94199 ***
The fix is not released in a stable portage version. That bug is talking about problems due to chmod'ing symlinks; this bug discusses problems with ch*own*'ing a ch*grp*'ing symlinks. The patch to the stable version of portage disables chmod'ing symlinks, but still runs chown and chgrp. Therefore, this bug is not fixed, and it will not be fixed until Portage either excludes symlinks from getting chown'd and chgrp'd (as well as excluding them from chmod'ing) or until it uses the -h option to chown and chgrp, as explained in the original bug report for this bug. (I believe the -h option is the best choice.)
Created attachment 63985 [details, diff] Modify symlinks with custom lchown and lchgrp Apologies. Too much bug wrangling late at night and early in the morning. This patch separates the handling of symlinks and adds default no-op lchown and lchgrp implementations. These would be overidden by whatever profile is in use so as to allow the appropriate method for modifying permissions on symlinks. Is this acceptable for the BSD and Darwin people?
This patch is applied to 2.0.53. However, the default lchown and lchgrp implementations specify "-h" as per the GNU tools method. If these don't work in the other USERLANDs, they'll need to be overrided in the profiles.
Fixed in 2.0.53
*** Bug 111019 has been marked as a duplicate of this bug. ***
