SELinux Archive on lore.kernel.org
 help / color / Atom feed
From: William Roberts <bill.c.roberts@gmail.com>
To: Laurent Bigonville <bigon@debian.org>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: CFLAGS overridden by distribution build system
Date: Sat, 23 May 2020 10:59:18 -0500
Message-ID: <CAFftDdobT3E1MvFptyAKLBJ73KyrMOSS3m8DCnPX9+QF-Rk24Q@mail.gmail.com> (raw)
In-Reply-To: <d0fd6970-7aa6-c576-fb8a-1d1293416e97@debian.org>

On Sat, May 23, 2020 at 5:57 AM Laurent Bigonville <bigon@debian.org> wrote:
>
> Hello,
>
> The current build system of the userspace is setting a lot of CFLAGS,
> but most of these are overridden by the distributions when building.
>
> Today I received a bug report[0] from Christian Göttsche asking me to
> set -fno-semantic-interposition again in libsepol. I see also the same
> flag and also a lot of others set in libselinux and libsemanage build
> system.

Why would it be again? The old DSO design made that option impotent.
Clang does it by default.

>
> For what I understand some of these are just needed for code quality
> (-W) and could be controlled by distributions but others might actually
> need to be always set (-f?).

If you look at the Makefiles overall in all the projects, you'll see hardening
flags, etc. Libsepol has a pretty minimal set compared to say libselinux, but
they all get overridden by build time CFLAGS if you want.

>
> Shouldn't the flags that always need to be set (which ones?) be moved to
> a "override CFLAGS" directive to avoid these to be unset by distributions?

If you we're cleaver with CFLAGS before, you could acually circumvent
the buildtime
DSO stuff. While i'm not opposed to adding it to immutable flag, if
you're setting
CFLAGS, you're on your own. At least with the current design.

I have no issues with adding it to override, but we would have to
overhaul a bunch
of them and make them consistent.

>
> Kind regards,
>
> Laurent Bigonville
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961329
>

      reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-23 10:56 Laurent Bigonville
2020-05-23 15:59 ` William Roberts [this message]

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=CAFftDdobT3E1MvFptyAKLBJ73KyrMOSS3m8DCnPX9+QF-Rk24Q@mail.gmail.com \
    --to=bill.c.roberts@gmail.com \
    --cc=bigon@debian.org \
    --cc=selinux@vger.kernel.org \
    /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

SELinux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \
		selinux@vger.kernel.org
	public-inbox-index selinux

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git