Bug 15891 – RFE: default %defattr value

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 15891 - RFE: default %defattr value

Summary:	RFE: default %defattr value

Status:	CLOSED WORKSFORME

Aliases:	None

Product:	Red Hat Raw Hide
Classification:	Retired
Component:	rpm-build (Show other bugs)
Sub Component:
Version:	1.0
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Jeff Johnson
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:	FutureFeature

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2000-08-09 17:22 EDT by Dmitry V. Levin
Modified:	2008-05-01 11:37 EDT (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Enhancement
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2001-02-21 14:07:11 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Dmitry V. Levin 2000-08-09 17:22:55 EDT

To simplify .spec-files for building packages in BUILDROOT environment,
I suggest to use value of %_defattr macro (if any) as default %defattr
value,
instead of currently used (-,-,-,-).
%_defattr should be defined somewhere in /usr/lib/rpm/macros, for example,
%_defattr       %%defattr(-,root,root,755)
Of course, %defattr directive overrides value of %_defattr macro in each
%file section where %defattr ever used.

Patch to rpm-3.0.5 listed below:
--- rpm-3.0.5/build/files.c~	Mon Jun 26 21:28:51 2000
+++ rpm-3.0.5/build/files.c	Fri Jun 30 05:52:28 2000
@@ -1221,6 +1221,8 @@
     s = getStringBuf(pkg->fileList);
     files = splitString(s, strlen(s), '\n');
 
+	parseForAttr(rpmExpand("%_defattr", NULL), &fl);
+
     for (fp = files; *fp != NULL; fp++) {
 	s = *fp;
 	SKIPSPACE(s);

Comment 1 Pavel Roskin 2001-01-10 15:40:44 EST

It's a serious security problem.

RPM allows to build packages a normal user. In this case it hardcodes the
user ID of the builder into the package, unless the attributes of the
files are overwritten by the "%defattr" tag.

This means that if I build the RPM with "rpm -tb foo.tgz" as user and
install the package as root, the installed files are owned by me, user!

This is a very bad default behaviour of RPM and should be corrected.

Regarding the proposed patch, I doubt that it can be applied as is because
of backward compatibility concerns. Some packages are buildable only as root
and they rely on the current default value of %defattr.

My proposal (also not ideal) - if the package is built by a normal user,
replace the UID and GID of that user with "root" before applying the
%defattr rules.

Comment 2 Jeff Johnson 2001-02-21 14:07:06 EST

rpm *always* uses the uid/gid from the header metadata, never uses the uid/gid
in payload
headers, so the scope of this problem is basically to use of rpm2cpio to extract
the payload
outside of rpm.

The right thing to do is to map the uid/gid when creating the payload, using
exactly
the same values as are in the metadata, and then to make use of %defattr on by
default,
rather than off by default. 

FWIW, I see little reason to implement as you've suggested, but every reason to
make
use of %defattr (with appropriate configurable defaults of course, just not a
macro as you've
suggested) on by default.

Changing component.

Comment 3 Jeff Johnson 2002-02-05 13:02:23 EST

rpm-4.0.4 contains a commented out macro for %files
in /usr/lib/rpm/<arch>-linux/macros. Uncommenting
the macro will insert a %defattr(-,root,root) right
after a %files marker.

This gets the job done almost everywhere, but cannot
be enabled by default because of current packaging
horkage.

Note You need to log in before you can comment on or make changes to this bug.