The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interesting dpkg issue, plus thoughts...

Since so many people seem to be interested in this:

Until version 1.4.0.9, three programs in dpkg-dev used the value of
&getlogin() to set the ownership of files they created:

 * dpkg-distaddfile used it to set the ownership of debian/files  
 * dpkg-gencontrol used it to set the ownership of debian/files  
 * dpkg-shlibdeps used it to set the ownership of debian/substvars

They did this so that when they were called from 'sudo ./debian/rules
binary' (or whatever other root-granting program was being used), they
would create 'debian/files' and 'debian/substvars' files that were
likely to be editable by the user running the program.  This was not a
critical part of the package building process; it was simply a
convenience to the user.

Unfortunately, &getlogin() is not always a reliable source of
information (for reasons already enumerated); and controllib.pl (the
library used by these three programs) did not properly check the
return value of &getlogin().  This led to package builds failing with
the mysterious "chown new files list file" message when &chown was
called on the new 'debian/files' using the null list returned by
&getlogin().

In 1.4.0.9, I changed controllib.pl to use a better heuristic for
determining the desired owner of 'debian/files' and
'debian/substvars':

 * if $LOGNAME is defined, use its value
 * else if &getlogin() is successful, use its value
 * else use the login information for the uid of the process if available
 * else exit with an error

In all cases where either $LOGNAME or &getlogin() is not available, or
where their values do not match, 'controllib.pl' prints an error
message for the user.

Ideally, we want to always set the ownership of the created files to the
uid of the process that originally ran the 'sudo ./debian/rules
binary' (or whatever).  So far as I can tell, though, there is no
reliable way to get that information, at least not while permitting
the use of multiple different sudo-like programs.  I believe the
current heuristic to be better than the use of &getlogin() alone,
though I suppose others might reasonably disagree.

Whether or not getlogin() should ever return NULL is an issue I will
leave up to more interested parties to debate.  It is, however, a hard
reality of life on most UNIX systems, and I see no point in making a
package build fail based on a non-critical error, especially when I
believe the current heuristic to be better anyway.

The real solution, in any case, is not to build packages as the root
user, which, thanks to Joost "fakeroot" Witteveen, is now possible.
Have I mentioned how much I like "fakeroot"?


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .