[Rpm-maint] Automatic BuildRoot by default?

[Panu Matilainen]

On Thu, 12 Jun 2008, Stanislav Brabec wrote:

> Tom "spot" Callaway wrote:
>> On Thu, 2008-06-12 at 14:48 +0200, Jindrich Novy wrote:
>>
>>> Opinions?
>>
>> One of the reasons why the mktemp option is appealing is because it is
>> not predictable, and helps lessen the security risks of knowing where
>> the buildroot is going to be and inserting malicious files.
>
> This security problem exists from the early rpm versions and comes from
> lines:
> %install
> rm -rf $RPM_BUILD_ROOT
> mkdir -p $RPM_BUILD_ROOT
>
> Anybody can use race condition to create more permissive directory.

That assumes "anybody" can create directories in the buildroot root, which 
of course is the case with the now typical %{_tmppath}/%{name}.... 
buildroot. The situation is fairly different with the suggested 
%{_topdir}/BUILDROOT/<something> buildroot as %{_topdir} is typically more 
or less private: keep in mind that in rpm.org HEAD the default %{_topdir} 
is defined as "%(echo $HOME)/rpmbuild" so unless overridden, it's "safe 
ground".

Of course it's still possible to override the topdir to something that's 
shared between different users, but it's still a different game from 
current %{_tmppath} use: I wouldn't expect people to share their 
%{_topdir} with malicious users (if they do, that's their headache).

> Using mktemp() and keeping these lines in spec files will not improve
> security in any way.

Yes, IF mktemp() is used in a shared directory such as /tmp or 
/var/tmp. In the case of %{_topdir}/BUILDROOT/%{name}....XXXXXX it doesn't 
really improve security either, it just ensures a fully clean buildroot 
for a package (even if you forget to add the two lines at beginning of 
%install, something that happens to me every now and then ;) and makes 
sure packages are "buildroot clean", ie aren't playing dumb games with 
hardcoded assumptions.

Whether those "advantages" are worth breaking --short-circuit I dunno - I 
certainly use -bi --short-circuit all the time to test %install/%files 
correctness and would miss it sorely. One possibility would be using a 
non-predictable buildroot only for --rebuild but...

> Secure build implies change of spec coding style. If rpmbuild itself
> will do rmdir()+mkdir() safely (correct privileges, force fail if
> directory exists and it is not possible to remove it), then the worst
> problem with the static BuildRoot is a DoS. I think that local DoS on
> rpmbuild is not a problem, because it already exists: one user adding
> foo.spec to SPECS makes impossible to build foo by anybody else.
>
> The "safe BuildRoot create" patch already exists in openSUSE.

Oh, I've somehow missed that entirely (I do every now and then look at 
what distros are patching rpm with :), I'll have a look.

>> The only reason we use mktemp in there is because we couldn't make rpm
>> code changes to use the native glibc functions. As to rpm
>> --short-circuit, well, I honestly think we should think long and hard
>> about whether we want to keep it around.
>
> If mktemp() would be preferred anyway, rpmbuild could store
> package<->buildroot map in home directory. But I think, that it is an
> overkill, as build directories and source directories are static.

Yeah, sounds like an overkill to me too.

 	- Panu -