When using FEATURES="buildpkg", portage currently creates the tarballs of the packages (default: in /usr/portage/packages) with ownership of root:root. This causes problems for two use cases related to PKGDIR on NFS: (1) no_root_squash becomes a requirement, which may be unwanted (2) in a kerberos-enabled NFSv4 environment, this causes the files to be instead owned by nobody:nobody. This is most likely unwanted behaviour. Reproducible: Always Steps to Reproduce: 1. have PKGDIR on kerberized NFSv4 share or on root_squashed NFS share 2. emerge something with FEATURES="buildpkg" Actual Results: built pkg tar.bz2 is owned by nobody:nobody Expected Results: file is owned by portage:portage ownership of root:root is not possible in the described environments. Solution could be to make either the creation of the tar-file be performed by user portage, or create the file somewhere else and move it to the correct location with correct permissions. zmedico suggested to pipe the tar output to bzip2 running as portage user. Note that user root would not retain write access to the file, but user portage would. As the files are created as world readable, reading them is not a problem. Other workarounds, like mapping anonymous to another user, leave a security problem unadressed: users with access to that anonymous mapping get write access to the files.
I'm resistant to the idea of supporting any file system where root can't do anything it wants. It seems like a rather annoying departure from standard unix semantics.
Has there been any changes on opinions on adding such a feature? There are features such as userfetch, and userpriv could we also get userbinpkgbuild? I'm in a similar situation where I mount a binpkg kerberos-enabled NFS share. I currently have to switch users to write newly built binpkgs to it.
