[Bug 1176580] no rescue mode in menu
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1176580
Chris Lumens <clumens(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pbokoc(a)redhat.com,
| |zach(a)oglesby.co
Component|LiveCD |install-guide
Version|21 |devel
Assignee|mclasen(a)redhat.com |pbokoc(a)redhat.com
Product|Fedora |Fedora Documentation
QA Contact| |docs-qa(a)lists.fedoraproject
| |.org
--- Comment #2 from Chris Lumens <clumens(a)redhat.com> ---
Please change the documentation to remove any references to rescue mode on the
live installation boot menu. I've removed that boot option. Thanks!
--
You are receiving this mail because:
You are the QA Contact for the bug.
8 years, 8 months
[Bug 1255542] New: Improve first opening Introduction paragrph of Selinux Users and Admistrator Guide
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1255542
Bug ID: 1255542
Summary: Improve first opening Introduction paragrph of Selinux
Users and Admistrator Guide
Product: Fedora Documentation
Version: devel
Component: security-guide
Assignee: sparks(a)redhat.com
Reporter: lsatenstein(a)yahoo.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: pkennedy(a)redhat.com, security-guide-list(a)redhat.com,
sparks(a)redhat.com, zach(a)oglesby.co
Description of problem:
Paragraph reads
Security-Enhanced Linux (SELinux) is an implementation of a mandatory access
control mechanism in the Linux kernel, checking for allowed operations after
standard discretionary access controls are checked. It was created by the
National Security Agency and can enforce rules on files and processes in a
Linux system, and on their actions, based on defined policies.
Version-Release number of selected component (if applicable):
How reproducible:
What is the difference in meaning between checked and approved and validated?
Should this introduction read...
Security-Enhanced Linux (SELinux) is an implementation of a mandatory access
control mechanism in the Linux kernel, allowing approved operations after
standard discretionary access controls are validated. It was created by the
National Security Agency and can enforce rules on files and processes in a
Linux system, and on their actions, based on defined policies.
Steps to Reproduce:
1.
2.
3.
Actual results:
Checking does not mean acceptance or refusal. Suggest the replacement text.
Expected results:
Additional info:
--
You are receiving this mail because:
You are the QA Contact for the bug.
8 years, 8 months
[Bug 1254033] New: Chapter 9.2 advice on using /proc/self/fd to close file descriptors before execve is dangerously wrong
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1254033
Bug ID: 1254033
Summary: Chapter 9.2 advice on using /proc/self/fd to close
file descriptors before execve is dangerously wrong
Product: Fedora Documentation
Version: devel
Component: defensive-coding-guide
Assignee: fweimer(a)redhat.com
Reporter: sstewartgallus00(a)mylangara.bc.ca
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: fweimer(a)redhat.com
Description of problem:
The documentation advises to open /proc/self/fd after forking and close the
file descriptor entries found in there before calling execve. However, in a
multi-threaded environment many memory allocators may deadlock after fork
(opendir, and readdir may allocate memory.) As well, most commonly programmers
implement this by looping over /proc/self/fd while closing file descriptors
which is unsafe because it is like looping over a list while removing entries
from it at the same time. Instead, one should set the close on execute bit on
these file descriptors when looping over the directory entries (probably using
the FIONCLEX ioctl for speed.)
--
You are receiving this mail because:
You are the QA Contact for the bug.
8 years, 8 months
[Bug 1254032] New: 8.1.1 advice on using getpid to avoid fork problems is dangerously wrong
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1254032
Bug ID: 1254032
Summary: 8.1.1 advice on using getpid to avoid fork problems is
dangerously wrong
Product: Fedora Documentation
Version: devel
Component: defensive-coding-guide
Assignee: fweimer(a)redhat.com
Reporter: sstewartgallus00(a)mylangara.bc.ca
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: fweimer(a)redhat.com
Description of problem:
If one forks a process, the original process dies and then the second one forks
again the last forked process can have the same pid as the original and so
getpid will not detect a change. This was a widely noted weakness in LibreSSL
(see https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux.)
How reproducible:
This is very probably systematically reproducible in possibly affected
libraries but in practise should never really happen.
--
You are receiving this mail because:
You are the QA Contact for the bug.
8 years, 8 months