All of lore.kernel.org
 help / color / mirror / Atom feed
From: guido@trentalancia.net (Guido Trentalancia)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH v3] xserver: restrict executable memory permissions
Date: Fri, 30 Dec 2016 18:04:53 +0100	[thread overview]
Message-ID: <1483117493.7186.3.camel@trentalancia.net> (raw)
In-Reply-To: <CAJ2a_DeObY2AYCE_iZe_UpyvvFsRoQ4B9T_e-qFp_+wfqXNF_w@mail.gmail.com>

On Fri, 30/12/2016 at 17.07 +0100, cgzones wrote:
> Hi,
> 
> 2016-12-30 2:42 GMT+01:00 Guido Trentalancia via refpolicy
> <refpolicy@oss.tresys.com>:
> > 
> > Hello again.
> > 
> > I have double-checked and the difference between /usr/share and
> > /var/lib is between architetture-independent and single-machine
> > data, not between read-only and writable.

I correct myself. The former also implies read-only files.

> Quoting FHS 3.0:
> 
> /usr/share
> "The /usr/share hierarchy is for all read-only architecture
> independent data files."
> (http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html)
> 
> /var/lib
> "This hierarchy holds state information pertaining to an application
> or the system. State information is data that programs modify while
> they run, and that pertains to one specific host."
> (http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s08.html)
> 
> > 
> > I hope it helps.
> > 
> > Regards,
> > 
> > Guido
> > 
> 
> Btw, I am not against this patch, just wanted to make sure this
> specific change was intentional and note that it's a bit unhandsome.

I confirm, it is a sort of bug in xserver (the actual package, not the
policy module).

Regards,

Guido

  reply	other threads:[~2016-12-30 17:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-28 17:20 [refpolicy] [PATCH] xserver: only run in confined mode and restrict execmem permissions Guido Trentalancia
2016-12-28 19:56 ` [refpolicy] [PATCH v2] xserver: restrict executable memory permissions (was "only run in confined mode and restrict execmem permissions") Guido Trentalancia
2016-12-30  0:36   ` [refpolicy] [PATCH v3] xserver: restrict executable memory permissions Guido Trentalancia
2016-12-30  1:06     ` cgzones
2016-12-30  1:19       ` Guido Trentalancia
2016-12-30  1:42       ` Guido Trentalancia
2016-12-30 16:07         ` cgzones
2016-12-30 17:04           ` Guido Trentalancia [this message]
2016-12-30 19:32     ` Chris PeBenito
2016-12-30 22:06       ` Guido Trentalancia
2016-12-30 22:07       ` [refpolicy] [PATCH v4] " Guido Trentalancia
2016-12-31 15:56         ` Chris PeBenito
2016-12-31 16:00           ` Guido Trentalancia
2016-12-31 16:02           ` [refpolicy] [PATCH v5] " Guido Trentalancia
2016-12-31 16:27             ` Chris PeBenito
2016-12-31 16:38               ` Guido Trentalancia
2016-12-31 16:43               ` [refpolicy] [PATCH v6] " Guido Trentalancia
2017-01-02 18:38                 ` Chris PeBenito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1483117493.7186.3.camel@trentalancia.net \
    --to=guido@trentalancia.net \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.