I couldn't agree more. Despite Lennart's repeatedly mentioning that this is substantially -- if not primarily -- a security feature, a lot of people are disregarding it. I think it's pretty dangerous and counter-productive in the long-term to have different security settings across the Fedora products.
SELinux is a great illustration of applying security settings consistently. Everyone has had problems with SELinux, especially when the target policy package was less mature. Everyone. Yet, Fedora ships in enforcing mode in all three products, even though in some people's eyes it's unnecessary for Workstation. (I don't share this opinion; I like SELinux enforcing everywhere.) There's another lesson from SELinux as well: Neither RHEL nor Fedora ship SELinux in Multi-Level Security (MLS) mode, allowing users to run unconfined_t as a compromise. Nonetheless, we're consistent everywhere with this setting. While SELinux is still daunting, the consistency of Fedora's default configuration ameliorates that to some extent. > Hacky, but it'd work for me if it worked transparently. (Or, make /usr/bin/tmux et al be shell scripts which do the work.) On the topic of consistency, it makes the most sense to do same as /usr/bin/yum currently does for nohup (tmux/screen/etc can become actual wrappers): executable="/usr/bin/dnf" msg="Yum command has been deprecated, redirecting to '$executable $@'.\n"\ "See 'man dnf' and 'man yum2dnf' for more information.\n"\ "To transfer transaction metadata from yum to DNF, run:\n"\ "'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'\n" echo -e $msg >&2 exec $executable "$@" On Wed, Jun 1, 2016 at 2:57 PM, Matthew Miller <mat...@fedoraproject.org> wrote: > On Wed, Jun 01, 2016 at 02:08:13PM -0400, Solomon Peachy wrote: > > > Fedora as a distro needs to determine which of these assumptions are > > > valid *for Fedora* and set the defaults accordingly, as well as > > > determining if/how to give users the freedom to set them differently. > > I don't think it's possible to come up with a default that is globally > > applicable. Even the current status quo has its problems. > > Well, we do end up needing _some_ default, since that's what a default > is. Theoretically, we could have different defaults for Atomic/Cloud, > Server, and Workstation depending on needs of the appropriate target > audiences we've defined — but this is such a big thing that I think > it's valuable to give some weight to consistency. > > > > -- > Matthew Miller > <mat...@fedoraproject.org> > Fedora Project Leader > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
