[Fedora-packaging] Refining today's "don't touch system fs" guideline

[Tom 'spot' Callaway]

On Thu, 2006-10-12 at 20:20 +0200, Axel Thimm wrote:

> How about extending the rule and having a root/non-root rule, too,
> e.g.

Well, keep in mind that the buildsystem is building everything as
non-root, so any "root" specific rules are not terribly valuable to
Fedora (but are almost certainly good practices for packaging in
general).

> o Package builds should yield the same results irrespective of the
>   packaging process' uid/gid, for example builds under root and
>   non-root users should behave the same.

While this is accurate, if we add it, it should be a SHOULD, and not a
MUST. It is a SHOULD in Axel's wording, but I just want to emphasize the
point. :)

> o Build scripts of packages (%prep, %build, %install and %check) may
>   only alter files (create, modify, delete) under %{buildroot},
>   %{_builddir} and valid temporary locations like /tmp, /var/tmp (or
>   $TMPDIR or %{_tmppath} as set by the rpmbuild process).
>   %{buildroot} should only be allowed to be altered in %install
>   scripts.
> 
>   Note I: The first part of this rule is automatically
>   fulfilled for typical non-user build process uids but the packager
>   should not rely on that, since users may rebuild the src.rpm under
>   root

But we really don't want them too. Heck, I would wholeheartedly support
patching rpm to complain when rpmbuild is being run by UID 0. :)
Generally, people rebuilding packages as root don't know what they're
doing. These are the same sort of people who are liable to download
SRPMS willy-nilly, from any possible source (and for any possible
distribution) and rebuild them. So even if Fedora sets the bar high for
quality here, we still don't want people to think that rebuilding SRPMS
as root is a recommended or safe idea.


>   Note II: As a consequence $HOME and similar parts of the filesystem
>   are not to be used directly. Of course some of the allowed write
>   spaces like the builddir, buildroot or $TMPDIR may have been placed
>   under $HOME, so indirectly a user may be writing under $HOME, but
>   direct access to parts under $HOME are strictly forbidden.

Agreed. If an end-user wants to set their variables to brain-dead
locations, then they deserve whatever pain they get.

>   Note III: Cheating with relative paths (".." escapes) grants you a
>   ticket to packaging hell.

This really ought to be a MUST. Using relative paths ("..") in anything
involving a write operation should be actively discouraged. Perhaps even
using it at all should be discouraged. 

Example:

Version 1 of Package foo leaves some junk in a toplevel directory. When
we run make install, we get this junk as part of a glob.

To keep the install clean (and minimize the amount of bleeding from the
eyes of dealing with autotools), the packager does this:

cd ..
rm -rf foo*

But, in version 2 of the Package foo, they get rid of these files for
us, and incorporate the same command set in their build process, and
leave us in that toplevel directory. Suddenly, we've dropped down a
level and we're deleting all sorts of unexpected things. Hopefully, a
packager would catch this before he sent it to the buildsystem, and yes,
mock insulates us for this case (worst case, he kills himself and the
build fails). But for the end-user, not rebuilding in mock, they may do
more damage. Multiple relative paths ("../..") only make the damage
potential worse.

Just food for thought at 35,000 feet over the Pacific.

~spot
-- 
Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260

"We must not confuse dissent with disloyalty. We must remember always
that accusation is not proof and that conviction depends upon evidence
and due process of law. We will not walk in fear, one of another. We
will not be driven by fear into an age of unreason, if we dig deep in
our history and our doctrine, and remember that we are not descended
from fearful men -- not from men who feared to write, to speak, to
associate and to defend causes that were, for the moment, unpopular."
-- Edward R. Murrow, March 9, 1954