Comment # 9 on bug 1114383 from
Sorry, the commenters in #c1, #c2, #c3, #c4 and #c5 misunderstood me a bit.

I did NOT wrote this bug report to complain about /usr/lib64/libexec/kcheckpass
permissions in package kscreenlocker. The kscreenlocker problem was meant as an
example for a more general issue with Zypper and chkstat.

#c6 pointed this out correctly.
> Entries in /etc/permissions.local actually only work reliably for locally
> installed files like in /usr/local/... that are not managed by zypper. Or for
> overriding permissions of files that ship with set*id and thus call
> %set_permissions and %verify_permissions.

I do not think, that it is enough, that single packages call "chkstat --system
--set". This may work with the files listed in

/etc/permissions
/etc/permissions.d/*
/etc/permissions.easy
/etc/permissions.paranoid
/etc/permissions.secure

because these files are more or less static and only a limited number of
packages are affected. E.g. the files listed in /etc/permissions.easy come from
around 40 RPM packages on my TW installation. In theory each of the >=40
packages may call chkstat in postinstall scripts.

But Root can list any file in /etc/permissions.local, e.g. files from package
A.rpm and B.rpm. During a Zypper run, Zypper can for instance update packages
C.rpm and D.rpm. Then it is useless to call "chkstat", if C.rpm and D.rpm does
not contain files from /etc/permissions.{easy,paranoid,secure}. But if Zypper
updates the packages A.rpm, C.rpm and D.rpm, then Zypper should call chkstat to
update the permissions.

I find #c7 interesting:
> It might work to add

> %transfiletriggerin -- /
> /usr/bin/chkstat --system

> to permissions.spec to run chkstat at the end of every transaction.


You are receiving this mail because: