[Bug 784670] New: RPM macro %fdupes links files with different owner, group, or permissions

newer
[Bug 841322] New: HW-accelerated...

older
[Bug 840812] New: default ipsec...

bugzilla_noreply＠novell.com

11 Oct 2012 11 Oct '12

16:46

https://bugzilla.novell.com/show_bug.cgi?id=784670 https://bugzilla.novell.com/show_bug.cgi?id=784670#c0 Summary: RPM macro %fdupes links files with different owner, group, or permissions Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: All OS/Version: SUSE Other Status: NEW Severity: Major Priority: P5 - None Component: BuildService AssignedTo: mvyskocil@suse.com ReportedBy: jsmeix@suse.com QAContact: adrian@suse.com CC: security-team@suse.de Found By: Development Blocker: --- /usr/bin/fdupes finds files with identical content but does not care about owner, group, or permissions. Accordingly the RPM macro %fdupes links files with identical content but does not care about owner, group, or permissions. When there are two files with identical content which differ in owner, group, or permissions the RPM macro %fdupes overwrites one of them with a link which effectively lets the two files have same owner, group, and permissions. I think this is even a security issue. I think it can happen that a file with restricted permissions (e.g. a file in another sub-direcory with restricted permissions) becomes accessible via an unrestricted accessible link? E.g. assume there are two files with identical content -rw-r--r-- root root /etc/secure-stuff.conf -rw-rw-rw- root root /usr/share/doc/package/secure-stuff.conf-example and the RPM macro %fdupes overwrites /etc/secure-stuff.conf by a link (I know "-rw-rw-rw- root root" should not happen, it is only meant as a simple example to show the idea behind). I added our security team to Cc to have a look. The RPM macro %fdupes should be enhanced by a test that additionally compares owner, group, and permissions and only link files with identical content, owner, group, and permissions including owner, group, and permissions of all (parent) directories. As far as I see this issue affects the build of all our products. Therefore I filed the bug report for "BuildService" (and not just as a normal bug for the fdupes package) but I assigned it to the fdupes package bugowner. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

Show replies by date

bugzilla_noreply＠novell.com

12 Oct 12 Oct

09:03

New subject: [Bug 784670] RPM macro %fdupes links files with different owner, group, or permissions

https://bugzilla.novell.com/show_bug.cgi?id=784670 https://bugzilla.novell.com/show_bug.cgi?id=784670#c1 Michal Vyskocil changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High Status|NEW |NEEDINFO InfoProvider| |security-team@suse.de --- Comment #1 from Michal Vyskocil 2012-10-12 07:03:54 UTC --- Hallo security team, would you consider it as a security issue? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

bugzilla_noreply＠novell.com

10:15

New subject: [Bug 784670] RPM macro %fdupes links files with different owner, group, or permissions

https://bugzilla.novell.com/show_bug.cgi?id=784670 https://bugzilla.novell.com/show_bug.cgi?id=784670#c2 --- Comment #2 from Michal Vyskocil 2012-10-12 08:15:09 UTC ---

...

The RPM macro %fdupes should be enhanced by a test that additionally compares owner, group, and permissions and only link files with identical content, owner, group, and permissions including owner, group, and permissions

That's a trivial change - just add few lines into fdupes.c

...

of all (parent) directories.

OK, that's not that easy - we can't compare the lists of uid:guid:mode from the path as path's can be different. We cannot use set's as there is a counter-example /user-dir/root-dir/same-file /root-dir/user-dir/same-file thus we might create a list of the uid:guid:mode from the path, call uniq and compare the results. That one seems to be more easier writtable in bash ... however I am not sure if the effort is not pointless - are there any occurrences of it in our packages? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

bugzilla_noreply＠novell.com

10:42

New subject: [Bug 784670] RPM macro %fdupes links files with different owner, group, or permissions and across sub-package boundaries

https://bugzilla.novell.com/show_bug.cgi?id=784670 https://bugzilla.novell.com/show_bug.cgi?id=784670#c3 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|RPM macro %fdupes links |RPM macro %fdupes links |files with different owner, |files with different owner, |group, or permissions |group, or permissions and | |across sub-package | |boundaries --- Comment #3 from Johannes Meixner 2012-10-12 10:42:42 CEST --- It was in the hplip package where I found the issue: HPLIP's upstream "make install" installs (owner:group is root:root for all): -rw-r--r-- 962 /usr/share/hplip/fax/pstotiff -rw-r--r-- 778 /usr/share/hplip/fax/pstotiff.convs -rw-r--r-- 2084 /usr/share/hplip/fax/pstotiff.types and -rwxr-xr-x 962 /usr/lib/cups/filter/pstotiff -rw-r--r-- 778 /etc/cups/pstotiff.convs -rw-r--r-- 2084 /etc/cups/pstotiff.types The RPM macro %fdupes results (I leave out the file size): -rw-r--r-- /usr/share/hplip/fax/pstotiff lrwxrwxrwx /usr/share/hplip/fax/pstotiff.convs -> /etc/cups/pstotiff.convs lrwxrwxrwx /usr/share/hplip/fax/pstotiff.types -> /etc/cups/pstotiff.types lrwxrwxrwx /usr/lib/cups/filter/pstotiff -> ../../../share/hplip/fax/pstotiff -rw-r--r-- /etc/cups/pstotiff.convs -rw-r--r-- /etc/cups/pstotiff.types This causes several issues for HPLIP: /usr/lib/cups/filter/pstotiff is no longer executable which causes bnc#783810 (Faxing an image file using hplip fails) /usr/share/hplip/fax/pstotiff /usr/share/hplip/fax/pstotiff.convs and /usr/share/hplip/fax/pstotiff.types are in the main package "hplip" but /usr/lib/cups/filter/pstotiff /etc/cups/pstotiff.convs and /etc/cups/pstotiff.types are in the sub-package "hplip-hpijs" The RPM macro %fdupes links across sub-package boundaries which can result dangling symlinks if a sub-package or the main package is not installed. In my case "hplip" requires "hplip-hpijs" but "hplip-hpijs" does not require "hplip" so that the %fdupes link /usr/lib/cups/filter/pstotiff -> ../../../share/hplip/fax/pstotiff becomes dangling if only "hplip-hpijs" is installed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

bugzilla_noreply＠novell.com

11:23

New subject: [Bug 784670] RPM macro %fdupes links files with different owner, group, or permissions

https://bugzilla.novell.com/show_bug.cgi?id=784670 https://bugzilla.novell.com/show_bug.cgi?id=784670#c4 Michal Vyskocil changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|RPM macro %fdupes links |RPM macro %fdupes links |files with different owner, |files with different owner, |group, or permissions and |group, or permissions |across sub-package | |boundaries | --- Comment #4 from Michal Vyskocil 2012-10-12 09:23:02 UTC --- I made a patch to fdupes checks the st_uid, st_gid and st_mode for files. It works pretty well # default behavior is to compare file size / crc / content fdupes . ./root-owned-file ./root-owned-file-2 ./user-executable-file ./user-executable-file-2 ./user-owned-file ./user-owned-file-2 # -p mode checks the uid/gid/mode and return differences fdupes -p . ./user-executable-file ./user-executable-file-2 ./root-owned-file ./root-owned-file-2 ./user-owned-file ./user-owned-file-2 so the -p mode for fdupes is what you have requested. The %fdupes macro needs to be changed to call fdupes with -p as well. I've commited the patched fdupes to home:mvyskocil:branches:utilities - feel free to test if that matches your needs. I am still not convinced the complete path checking is needed, so this is not implemented. About sub-package boundaries - that can't be solved without a substantial change of the build process. As %fdupes is called on the end of %install section, there is no way how to give it a a content of subpackages. Therefor you as a package maintainer must call fdupes only on directories won't be slitted across packages. I have had the same problem in openjdk package, so you're not alone who have faced this problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

bugzilla_noreply＠novell.com

11:57

New subject: [Bug 784670] RPM macro %fdupes links files with different owner, group, or permissions

https://bugzilla.novell.com/show_bug.cgi?id=784670 https://bugzilla.novell.com/show_bug.cgi?id=784670#c5 --- Comment #5 from Johannes Meixner 2012-10-12 11:57:05 CEST --- Many thanks for the fast response! Because I provide HPLIP in the Printing project also for older products like SLE_11, SLE_11_SP1, SLE_11_SP2 I cannot use "fdupes -p" (I must work with what I get in the build environments). For my "hplip" package I will exchange the dumb %fdupes -s %{buildroot} call by a more specific call (or calls) only for particular directories where linking files with same content should be safe. Regarding complete path checking: I think the security experts should decide this because this is too complicated for me - e.g. what about if there are links in the path or what about different filesystems under different path with different capabilities regarding access permissions e.g. ACLs or such stuff... Regarding %fdupes links across sub-package boundaries: One more reason to have this issue reported under "BuildService" to have them at least aware of the issue. rpmlint does not show a dangling symlink warning in any case when there are links across sub-package boundaries. Currently I get for hplip only: ------------------------------------------------------------------------- $ osc remotebuildlog Printing hplip openSUSE_12.2 i586 | grep dangling [ 566s] hplip.i586: W: dangling-symlink /usr/share/hplip/fax/pstotiff.types /etc/cups/pstotiff.types [ 566s] hplip.i586: W: dangling-symlink /usr/share/hplip/fax/pstotiff.convs /etc/cups/pstotiff.convs ------------------------------------------------------------------------- rpmlint finds links from the main package to files in a sub-package but not links from a sub-package to files in the main package. And the above dangling-symlink warnings are false-positives because here the main package requires the sub-package. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

bugzilla_noreply＠novell.com

12:16

New subject: [Bug 784670] RPM macro %fdupes links files with different owner, group, or permissions

https://bugzilla.novell.com/show_bug.cgi?id=784670 https://bugzilla.novell.com/show_bug.cgi?id=784670#c6 --- Comment #6 from Michal Vyskocil 2012-10-12 10:16:46 UTC --- (In reply to comment #5)

...

Many thanks for the fast response!

Because I provide HPLIP in the Printing project also for older products like SLE_11, SLE_11_SP1, SLE_11_SP2 I cannot use "fdupes -p" (I must work with what I get in the build environments).

That't not hard - if you have useforbuild option enabled, just link the fdupes package from openSUSE:Factory to your project (and limit the build on older distributions) once the fixed version appear here. Then the fixed package will be installed in your buildroot and -p will be used automatically.

...

Regarding complete path checking:

I think the security experts should decide this because this is too complicated for me - e.g. what about if there are links in the path or what about different filesystems under different path with different capabilities regarding access permissions e.g. ACLs or such stuff...

sure - that's still an opened question to @security-team.

...

Regarding %fdupes links across sub-package boundaries:

One more reason to have this issue reported under "BuildService" to have them at least aware of the issue.

rpmlint does not show a dangling symlink warning in any case when there are links across sub-package boundaries.

Can I ask you to split this particular issue to the separate bug? You can simply clone this one and limit it to the dangling symlink problem. I'll move this one to factory then. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.