On 22 Sep 2003 Lisa Seelye <[EMAIL PROTECTED]> wrote:
> The problem is that Portage is invoking '`which gcc` -dumpversion'
> through distcc, for some reason or another, and distcc is creating a
> lock file owned by root. So its a "Lisa jumped the gun, even though she
> was so sure" problem and not a distcc problem. ("oops")
That's OK. There is an issue here that ought to be fixed though, even
if it is not exactly a bug. That is that distcc no longer uses
directories that are strictly distinguished by the process's uid, and
therefore we have to cope with different accounts using the same
working directory, which can cause permissions problems.
Leaving aside Gentoo-specific issues, it is not common for people to
do "sudo make install", which will sometimes run another compilation.
(Doing so is probably a Makefile bug according to GNU standards but it
does happen.) That invocation will see my $HOME not root's, and might
create a root-owned file in my working directory.
I see similar behaviour from time to time by running package
management or hardware control programs through sudo that leave uid 0
files in my home directory.
One way, as I think Lisa suggested, is to go back to putting the uid
in the directory name. But that puts us right back where we started
with respect to allowing compilations run by one uid to be viewed by
another, which is probably a desirable thing.
distcc can handle some of these situations better than it does now.
For example the particular case Lisa reported might be fixed by
e.g. removing lock files we don't have permission to open. But I
don't think a complete solution is possible: if root creates the
distcc_dir without giving anyone else permission to open it then we're
stuck.
--
Martin
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
