[Bug 743020] New: rngd is missing initscript, attached
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: rngd is missing initscript, attached
https://bugzilla.redhat.com/show_bug.cgi?id=743020
Summary: rngd is missing initscript, attached
Product: Fedora
Version: 15
Platform: All
OS/Version: Linux
Status: NEW
Status Whiteboard: bzcl34nup
Severity: high
Priority: unspecified
Component: rng-tools
AssignedTo: jgarzik(a)redhat.com
ReportedBy: juan.oropeza(a)oracle.com
QAContact: extras-qa(a)fedoraproject.org
CC: cra(a)wpi.edu, mattdm(a)mattdm.org, jgarzik(a)redhat.com,
ianburrell(a)gmail.com, pizza(a)shaftnet.org,
paul(a)xelerance.com, triage(a)lists.fedoraproject.org,
avagarwa(a)redhat.com, juan.oropeza(a)oracle.com
Estimated Hours: 0.0
Classification: Fedora
Story Points: ---
Clone Of: 215371
Type: ---
+++ This bug was initially created as a clone of Bug #215371 +++
rngd should always be started in platforms with hardware random support, but
package provides no initscript to start the rngd.
--- Additional comment from paul(a)xelerance.com on 2006-11-13 13:21:28 EST ---
Created attachment 141082
rngd initscript
--- Additional comment from paul(a)xelerance.com on 2007-01-25 21:49:16 EST ---
Please try to get the init script for rngd into the package before FC7test1
feature freeze. I can't make it easier then I already did by supplying the init
script.
--- Additional comment from paul(a)xelerance.com on 2007-01-30 12:58:47 EST ---
Still an issue for rng-utils-2.0-1.14.1.fc6
--- Additional comment from paul(a)xelerance.com on 2007-01-30 13:03:47 EST ---
Created attachment 146934
Updated version of rngd.init supporting 2.6.19 style rng kernel modules
Updated version of rngd.init supporting 2.6.19 style rng kernel modules
--- Additional comment from paul(a)xelerance.com on 2007-01-30 13:12:16 EST ---
Created attachment 146935
Fix to previous version for properly modprobing hwrng
sorry about that. previous version is broken.
--- Additional comment from cra(a)wpi.edu on 2007-02-12 19:44:41 EST ---
You should change version to devel.
There is a commented out invocation of rngd in /etc/rc.d/rc.sysinit:
# Use the hardware RNG to seed the entropy pool, if available
#[ -x /sbin/rngd -a -c /dev/hw_random ] && rngd
if [ -f /etc/crypttab ]; then
s=$"Starting disk encryption using the RNG:"
Not sure why this is commented out, but it may be necessary for starting disk
encryption that follows it.
--- Additional comment from triage(a)lists.fedoraproject.org on 2008-04-04
00:39:59 EDT ---
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
--- Additional comment from paul(a)xelerance.com on 2008-04-07 17:54:03 EDT ---
>From Fedora 9 beta 1:
/etc/rc.d/rc.sysinit:#[ -x /sbin/rngd -a -c /dev/hw_random ] && rngd
It is still not using rngd on system start. This means crypto software like
Openswan cannot use any P4/AMD hardware random.
--- Additional comment from mike(a)miketc.net on 2008-05-02 23:25:00 EDT ---
Bug has been assigned and changed to rawhide so it's up to date with latest
release/development.
Also, maybe you could show what version you are using currently and are you
fully updated to current rawhide?
--- Additional comment from triage(a)lists.fedoraproject.org on 2008-05-13
22:28:05 EDT ---
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Additional comment from mattdm(a)mattdm.org on 2008-05-23 12:24:36 EDT ---
See bug #130350 for discussion of why the line in rc.sysinit is commented out.
Seems like a separate init script (or some fancy upstart incantation) may be
the
way to go, but the underlying flaw in the daemon maybe should get fixed too.
(Perhaps this needs to be split into two separate bugs?)
This is still an issue in fully-updated rawhide, by the way:
initscripts-8.76.2-1, rng-utils-2.0-1.15.1.fc9
--- Additional comment from ianburrell(a)gmail.com on 2008-09-20 18:22:57 EDT ---
Created attachment 317293
Fixed version of init script
The latest version of init script has a couple of syntax errors. This script
fixes the syntax errors.
--- Additional comment from triage(a)lists.fedoraproject.org on 2008-11-25
20:51:16 EST ---
This bug appears to have been reported against 'rawhide' during the Fedora 10
development cycle.
Changing version to '10'.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Additional comment from triage(a)lists.fedoraproject.org on 2009-11-18
02:44:58 EST ---
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Additional comment from triage(a)lists.fedoraproject.org on 2009-12-18
00:54:02 EST ---
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
--- Additional comment from pizza(a)shaftnet.org on 2010-01-27 15:50:11 EST ---
This is still a problem with rng-utils-2.0-4 in F12; there is no init script
present in the package.
--- Additional comment from juan.oropeza(a)oracle.com on 2011-10-03 11:41:55 EDT
---
this problem is still occurring in Fedora 15, is there a package update that
includes the startup script? I get the following output with the sample script
./rngd start
Probing for HRNG module
FATAL: Error inserting intel_rng
(/lib/modules/2.6.40.4-5.fc15.x86_64/kernel/drivers/char/hw_random/intel-rng.ko):
No such device
FATAL: Error inserting via_rng
(/lib/modules/2.6.40.4-5.fc15.x86_64/kernel/drivers/char/hw_random/via-rng.ko):
No such device
FATAL: Error inserting amd_rng
(/lib/modules/2.6.40.4-5.fc15.x86_64/kernel/drivers/char/hw_random/amd-rng.ko):
No such device
(Hardware RNG device inode not found)
./rngd: Cannot find a hardware RNG device to use.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years
[Bug 124246] grubby fatal error: unable to find a suitable template
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=124246
--- Comment #65 from kevin martin <kevintm(a)ameritech.net> 2011-10-31 17:44:04 EDT ---
Interestingly enough, it appears that it *did*, in fact, write out a new
grub2/grub.cfg for the new kernel:
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="1"
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
true
}
set timeout=10
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64.debug)' --class gnu-linux
--class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
echo 'Loading Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)'
linux /vmlinuz-3.2.0-0.rc0.git1.0.fc17.x86_64.debug
root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1
nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.2.0-0.rc0.git1.0.fc17.x86_64.debug.img
}
menuentry 'Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)' --class gnu-linux --class
gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
echo 'Loading Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)'
linux /vmlinuz-3.2.0-0.rc0.git1.0.fc17.x86_64
root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1
nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.2.0-0.rc0.git1.0.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.1.0-0.rc9.git0.3.fc17.x86_64' --class gnu-linux
--class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
echo 'Loading Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 ...'
linux /vmlinuz-3.1.0-0.rc9.git0.3.fc17.x86_64
root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1
nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.1.0-0.rc9.git0.3.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 (recovery mode)'
--class gnu-linux --class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
echo 'Loading Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 ...'
linux /vmlinuz-3.1.0-0.rc9.git0.3.fc17.x86_64
root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro single nouveau.noaccel=1
nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.1.0-0.rc9.git0.3.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.1.0-0.rc10.git0.1.fc17.x86_64' --class gnu-linux
--class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
echo 'Loading Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 ...'
linux /vmlinuz-3.1.0-0.rc10.git0.1.fc17.x86_64
root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1
nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.1.0-0.rc10.git0.1.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 (recovery mode)'
--class gnu-linux --class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
echo 'Loading Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 ...'
linux /vmlinuz-3.1.0-0.rc10.git0.1.fc17.x86_64
root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro single nouveau.noaccel=1
nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.1.0-0.rc10.git0.1.fc17.x86_64.img
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 0A889E4D889E36E3
chainloader +1
}
menuentry "Windows 7 (loader) (on /dev/sda2)" --class windows --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set=root B020C5A420C571C0
chainloader +1
}
menuentry "Windows Recovery Environment (loader) (on /dev/sda3)" --class
windows --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root F43CED0D3CECCBA4
drivemap -s (hd0) ${root}
chainloader +1
}
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
### BEGIN /etc/grub.d/90_persistent ###
### END /etc/grub.d/90_persistent ###
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 2 months
[Bug 124246] grubby fatal error: unable to find a suitable template
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=124246
kevin martin <kevintm(a)ameritech.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kevintm(a)ameritech.net
--- Comment #64 from kevin martin <kevintm(a)ameritech.net> 2011-10-31 17:41:52 EDT ---
Still happens with latest rawhide and grub2:
Running Transaction
Updating : kernel-debuginfo-common-x86_64-3.2.0-0.rc0.git1.0.fc17.x86_64
1/19
Updating : kernel-tools-3.2.0-0.rc0.git1.0.fc17.x86_64
2/19
Updating : kernel-tools-devel-3.2.0-0.rc0.git1.0.fc17.x86_64
3/19
Updating : kernel-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64
4/19
Installing : kernel-debug-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64
5/19
Updating : kernel-tools-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64
6/19
Installing : kernel-debug-devel-3.2.0-0.rc0.git1.0.fc17.x86_64
7/19
Updating : kernel-headers-3.2.0-0.rc0.git1.0.fc17.x86_64
8/19
Installing : kernel-devel-3.2.0-0.rc0.git1.0.fc17.x86_64
9/19
Installing : kernel-3.2.0-0.rc0.git1.0.fc17.x86_64
10/19
grubby fatal error: unable to find a suitable template
Installing : kernel-debug-3.2.0-0.rc0.git1.0.fc17.x86_64
11/19
grubby fatal error: unable to find a suitable template
Cleanup : kernel-tools-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64
12/19
Cleanup : kernel-tools-devel-3.1.0-0.rc10.git0.1.fc17.x86_64
13/19
Cleanup : kernel-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64
14/19
Cleanup : kernel-debuginfo-common-x86_64-3.1.0-0.rc10.git0.1.fc17.x86_64
15/19
Cleanup : kernel-3.1.0-0.rc9.git0.1.fc17.x86_64
16/19
grubby fatal error: unable to find a suitable template
grubby: doing this would leave no kernel entries. Not writing out new config.
Cleanup : kernel-headers-3.1.0-0.rc10.git0.1.fc17.x86_64
17/19
Cleanup : kernel-devel-3.1.0-0.rc9.git0.1.fc17.x86_64
18/19
Cleanup : kernel-tools-3.1.0-0.rc10.git0.1.fc17.x86_64
19/19
Verifying : kernel-tools-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64
19/19
VerifyTransaction time: 2.557
Transaction time: 598.320
Removed:
kernel.x86_64 0:3.1.0-0.rc9.git0.1.fc17
kernel-devel.x86_64 0:3.1.0-0.rc9.git0.1.fc17
Installed:
kernel.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-debug.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-debug-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-debug-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17
Updated:
kernel-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-debuginfo-common-x86_64.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-headers.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-tools.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-tools-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17
kernel-tools-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17
This happens to be a home compiled kernel (to get rid of the debug code so I
could install akmod-nvidia driver (since there's an unresolved error with
nouveau) so this was a "yum localinstall kernel*rpm". This bug has been open
since 2004?
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 2 months
[Bug 246879] Initscript Review (bittorrent)
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=246879
Paul Howarth <paul(a)city-fan.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |CLOSED
Resolution| |WONTFIX
Last Closed| |2011-10-20 04:37:22
--- Comment #3 from Paul Howarth <paul(a)city-fan.org> 2011-10-20 04:37:22 EDT ---
bittorrent has gone closed source and has been dropped from Fedora in F16, so
this isn't going to get done.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
needinfo canceled: [Bug 592089] SELinux is preventing /usr/lib/cups/backend/mfp "getattr" access to device /dev/mfpports/probe.
by Red Hat Bugzilla
Product: Fedora
Version: 12
Component: selinux-policy
Simon <simon(a)conditional-fee.co.uk> has canceled Bug Zapper
<triage(a)lists.fedoraproject.org>'s request for needinfo:
Bug 592089: SELinux is preventing /usr/lib/cups/backend/mfp "getattr" access to
device /dev/mfpports/probe.
https://bugzilla.redhat.com/show_bug.cgi?id=592089
------- Additional Comments from Simon <simon(a)conditional-fee.co.uk>
Hello again,
I bought a samsung CLX-6220FX which prints OK but each time I try to use the
smatpanel or unified driver configurater selinux block it:-
SELinux is preventing /opt/Samsung/mfp/bin/Configurator from using the
execstack access on a process.
***** Plugin allow_execstack (53.1 confidence) suggests ********************
If you believe that
None
should not require execstack
Then you should clear the execstack flag and see if
/opt/Samsung/mfp/bin/Configurator works correctly.
Report this as a bug on None.
You can clear the exestack flag by executing:
Do
execstack -c None
***** Plugin catchall_boolean (42.6 confidence) suggests *******************
If you want to allow unconfined executables to make their stack executable.
This should never, ever be necessary. Probably indicates a badly coded
executable, but could indicate an attack. This executable should be reported in
bugzilla
Then you must tell SELinux about this by enabling the 'allow_execstack'
boolean.
Do
setsebool -P allow_execstack 1
***** Plugin catchall (5.76 confidence) suggests ***************************
If you believe that Configurator should be allowed execstack access on
processes labeled unconfined_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep Configurator /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
023
Target Context
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
023
Target Objects Unknown [ process ]
Source Configurator
Source Path /opt/Samsung/mfp/bin/Configurator
Port <Unknown>
Host www.conditional-fee.co.uk
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.9.7-44.fc14
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name www.conditional-fee.co.uk
Platform Linux www.conditional-fee.co.uk
2.6.35.14-97.fc14.i686.PAE #1 SMP Sat Sep 17
00:22:29 UTC 2011 i686 i686
Alert Count 1
First Seen Sat 15 Oct 2011 17:11:32 BST
Last Seen Sat 15 Oct 2011 17:11:32 BST
Local ID b1f3562c-ec3e-48c8-9798-73102216119f
Raw Audit Messages
type=AVC msg=audit(1318695092.132:2519): avc: denied { execstack } for
pid=14265 comm="Configurator"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1318695092.132:2519): arch=i386 syscall=mprotect
success=no exit=EACCES a0=bfb02000 a1=1000 a2=1000007 a3=bfb020ec items=0
ppid=1 pid=14265 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500
sgid=500 fsgid=500 tty=(none) ses=268 comm=Configurator
exe=/opt/Samsung/mfp/bin/Configurator
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Hash: Configurator,unconfined_t,unconfined_t,process,execstack
audit2allow
#============= unconfined_t ==============
#!!!! This avc can be allowed using the boolean 'allow_execstack'
allow unconfined_t self:process execstack;
audit2allow -R
#============= unconfined_t ==============
#!!!! This avc can be allowed using the boolean 'allow_execstack'
I want to use the scanning capability but not if the method involves any
security risk (I've got another scanner -not as good)
What are the implications of using execstack -c None
please?
9 years, 3 months
needinfo canceled: [Bug 503149] Add features to Anaconda to aid installation on Apple computers
by Red Hat Bugzilla
Product: Fedora
Version: 15
Component: anaconda
Chris Murphy <bugzilla(a)colorremedies.com> has canceled Bug Zapper
<triage(a)lists.fedoraproject.org>'s request for needinfo:
Bug 503149: Add features to Anaconda to aid installation on Apple computers
https://bugzilla.redhat.com/show_bug.cgi?id=503149
------- Additional Comments from Chris Murphy <bugzilla(a)colorremedies.com>
This might need a separate bug report but I'll stick it in here for now.
Consistently I'm finding the partition type GUID is wrong in a number of cases:
The first ext4 partition listed in GPT (whether it's the 2nd partition entry or
the 5th) is thus far always the GUID for "EFI System Partition" GUID
C12A7328-F81F-11D2-BA4B-00A0C93EC93B. This is definitely incorrect, it should
be GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4 "Linux filesystem". The net result
of this bug is that there are two EFI System Partitions on a dual boot system,
one of which is the real EFI System partition, and the other is the partition
mounting as /boot. Probably not a good idea, should be fixed.
Subsequent partitions either ext4, btrfs, or xfs have partition type GUID
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 "Microsoft Windows basic data". This was
done for a long time under MBR, using the same partition type hex code as
Windows but linux filesystems have their own GUID which is
0FC63DAF-8483-4772-8E79-3D69D8477DE4. So it's a minor point, but ought to be
fixed.
"BIOS Boot" has the correct partition type GUID.
"Linux LVM" partitions also have the correct partition type GUID.
Last, all of my comments apply to F16 beta, so the version for this bug should
be changed to 16. Now that I've inundated everyone with multiple comments, I'll
remove the needinfo flag and await comments/questions on next steps.
9 years, 3 months