The Tuesday 09 December 2008 14:38:40 Hans-J. Ullrich, you wrote : > Am Dienstag, 9. Dezember 2008 schrieb Thomas Preud'homme: > > The Wednesday 10 December 2008 07:04:50 hendrik@topoi.pooq.com, you wrote : > > > On Mon, Dec 08, 2008 at 10:33:02AM -0500, Lennart Sorensen wrote: > > > > On Sun, Dec 07, 2008 at 04:11:04PM +0100, Hans-J. Ullrich wrote: > > > > > thanks for the list. I checked and found out, that a lot of > > > > > binaries in /sbin got permissions to rwxr-xr-- (root:root), but > > > > > they should have rwxrwxr-x. I wondered, as I never changed the > > > > > rights manually in the past and I am sure, I have not been hacked. > > > > > So there is only one explanation: an applicatiopn must have changed > > > > > it. Does someone know, which application is changing rights of > > > > > binaries below /sbin ? I suppose, it is either bastille (which I > > > > > installed and deinstalled a long time ago) or selinux (which i > > > > > still installed). > > > > > > > > > > Please, which manual did i miss to read ??? > > > > > > > > So far the only thing I have ever seen that causes that is silly > > > > people who mess with the umask of the root user (which causes dpkg to > > > > make lots of mistakes). > > > > > > Perhaps dpkg shouldn't rely on the umask of the root user? Perhaps is > > > should set it itself? Could this be considered a dpkg bug? > > > > It sounds reasonable indeed that dpkg don't rely on root umask. I don't > > want root to have a umask of 022 because usually I don't want users to > > read root file by default. Even if most of the time it's not a security > > issue, I don't want these file to be readable by users by default in case > > I forget to restrict rights of sensitive files. > > > > Furthermore, AFAIK files in /bin, /sbin and other bin directories aren't > > created, they are untared so that rights of these files are rights they > > have when tared by the debian maintener of the package. > > Hmm, so if this is really the way, packages are installed, then I should > always report to the maintainer of the package. On the other hand, I had > some problems with the package "eject". The installed binary got rwxr--r-- > ( with owners root:root), but in the package itself it got rwxr-xr-x > (root:root). I'm almost sure of what I said. For example I installed nicotine recently and my root umask is 027 but /usr/bin/nicotine is 755 so the umask is not used. I think umask is used in package installation only for files created by package scripts (postrm, prerm, etc.) > > When I reinstalled it, the permissions did not change. Then I deinstalled > it completely and reinstalled it again. Now it got the correct permissions: > rwxr-xr-x ! So far, so well. But after an upgrade some weeks later, the > permissions were wrong again (set as before). I could not explain that to > myself, but I could verify this behaviour. Lots of other binaries were > showing the same effects (for example the kde screensaver suddenly could > not have been unlocked any more, as the sticky bit was missing). > > So, if I would understand, how is and who is setting the permissions at > upgrades or installing, I could find out, what is going wrong. > > Who knows it ? As you said before you must have a program that change these permissions later. It must have a program to monitor change on a file, like a permanent lsof which would say you which program did the modifications. > > > Cheers > > Hans Regards, Thomas Preud'homme -- Why debian : http://www.debian.org/intro/why_debian
Attachment:
signature.asc
Description: This is a digitally signed message part.