Re: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions
On Fri, 12 Jan 2001, Johannes Poehlmann wrote:
> On Tue, Jan 09, 2001 at 10:37:31AM +0100, V man wrote:
>
> > On Mon, 8 Jan 2001 tytso@mit.edu wrote:
>
> > > From: Johannes Poehlmann <johannes@caldera.de>
>
> > > LSB says nothing about File Permissions.
> > >
> > > o This makes it possible to set up an LSB-conforming package
> > > and a LSB conforming Linux system where the application can
> > > not run on the linux system.
> > >
> > > I'm not sure we want to go here. Permissions generally are a system
> > > administrator issue much more than they are a distribution issue, and
> > > trying to word things so that we don't prohibit perfectly sane
> > > configurations might be very difficult.
> > Exactly! i would say that we should recognize it, maybe saying that
> > a kind of reasonable permission scheme is suggested (that is almost what
> > we say shipping with most distributions), and the system
> > manager is free
> > to use a mutch more restrictive one as mutch as a less restrictive one.
>
> Hi Luigi,
>
> We need to keep the Distributions/system managers freedom, to be as
> much restrictive or permissive he wants.
>
> To guarantee this, we must forbid Third Party Software Vendors ("ISVs")
> to demand more then a reasonable set of permissions.
>
> If we fail to do so, major ISV packages will demand arbitrary permissions
> and you as a Distributor had to grant them. If you do not, you will face
> bad press like: "Paranoia Linux claims to be LSB compliant but fails to
> execute LSB-compliant oracle/MSLinWord/Whatever".
>
I understand this point, and you are right.
This, for what i see, means that we need to keep a really good
equilibrium.
For what i know, the traditional set of permission we see in other
older Unixes is not suitable, since it usually is too open, and it makes
even difficoult for sysadmins to adopt a more restrictive set.
So, we should identify clearly, for example, which file we consider that
just the sysadmin should access, and then establish a set where there is
no need for user application to access them, nor to use SUID bits to
access them anyway (and also forbit SUID for every user).
I know this is difficoult, but this should be the goal.
For example i discovered oracle to use suid bits (as oracle user, of
course), to do many things. Just immagine how many exploits.
Think to those applications that have to be installed as root user!
Bests
Luigi Genoni
Reply to: