[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: access rights in /sbin and /bin [Update]



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).

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 ?


Cheers

Hans
  
>
> > -- hendrik
> >
> > > So if you ever set a umask for your root user, well don't and reinstall
> > > every affected package to fix the permissions.
> > >
> > > --
> > > Len Sorensen
> > >
> > >
> > > --
> > > To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
> > > with a subject of "unsubscribe". Trouble? Contact
> > > listmaster@lists.debian.org
>
> Greetings,
>
> Thomas Preud'homme



Reply to: