5:08 a.m.
Hi all,
I'm following the FedoraFAQ.org instructions for installing the NVDIA drivers and two
of the commands given for getting the drivers up and running don't work.
I'm entering
setsebool -P allow_execmod=1
but bash says the command is not found. Same with "init 3" for bringing FC5
down to the command line so i can enable the drivers.
I've been running both commands as root user with "su" and as a regular
user, but neither work. Any help here?
Jared
________________________________________________________________________
Check out AOL.com today. Breaking news, video search, pictures, email and IM. All on
demand. Always Free.
5:18 a.m.
Hi,
I'm entering
setsebool -P allow_execmod=1
Try /usr/sbin/setsebool -P allow_execmod=1
but bash says the command is not found. Same with "init 3"
for
bringing FC5 down to the command line so i can enable the drivers.
Right, it sounds like you're using the drivers from the nVidia website.
Don't. Use the ones from rpm.livna.org - these are especially wrapped up
to just install like a normal RPM. All you need do once the rpm is
installed is restart the X server (ctrl-delete) - warning, this will log
out when you do it.
________________________________________________________________________
Check out AOL.com today. Breaking news...
...AOL sucks
;-)
TTFN
Paul
--
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who
7:20 a.m.
PFJ wrote:
Hi,
> I'm entering
>
> setsebool -P allow_execmod=1
Try /usr/sbin/setsebool -P allow_execmod=1
> but bash says the command is not found. Same with "init 3" for
> bringing FC5 down to the command line so i can enable the drivers.
Right, it sounds like you're using the drivers from the nVidia website.
Don't. Use the ones from rpm.livna.org - these are especially wrapped up
to just install like a normal RPM. All you need do once the rpm is
installed is restart the X server (ctrl-delete) - warning, this will log
out when you do it.
Just a heads up. If you do want to use the nVidia installer with SELinux
enabled, the instructions on the FedoraFaq web site need to be updated.
Undo the changes to the booleans:
# /usr/sbin/setsebool -P allow_execstack 0
# /usr/sbin/setsebool -P allow_execmod 0
Then update the file contexts instead:
# /usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t
'/usr/lib/libGL(core)?\.so(\.[^/]*)*'
# /usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t
'/usr/lib/libnvidia.*\.so(\.[^/]*)*'
# /sbin/restorecon -v /usr/lib/libGL* /usr/lib/libnvidia*
In case of line wrapping, each of the three commands above should be on
a single line.
The above is based upon a discussion with Paul Howarth on the SELinux list.
HTH,
Marc Schwartz
8:07 a.m.
On Tuesday August 01 2006 8:20 am, Marc Schwartz wrote:
Marc: comments interspersed
Just a heads up. If you do want to use the nVidia installer with
SELinux
enabled, the instructions on the FedoraFaq web site need to be updated.
Undo the changes to the booleans:
# /usr/sbin/setsebool -P allow_execstack 0
# /usr/sbin/setsebool -P allow_execmod 0
ran these and immediately got a prompt with no messages
Then update the file contexts instead:
# /usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t
'/usr/lib/libGL(core)?\.so(\.[^/]*)*'
Running each of the next three produced readout that seemed to indicate errors
in syntax - i.e. instructions for proper running of the command:
/usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t'/usr/lib/libGL(core)?
\.so(\.[^/]*)*'
semanage {login|user|port|interface|fcontext|translation} -l [-n]
semanage login -{a|d|m} [-sr] login_name
semanage user -{a|d|m} [-LrRP] selinux_name
semanage port -{a|d|m} [-tr] [ -p protocol ] port | port_range
semanage interface -{a|d|m} [-tr] interface_spec
semanage fcontext -{a|d|m} [-frst] file_spec
semanage translation -{a|d|m} [-T] level
Primary Options:
-a, --add Add a OBJECT record NAME
-d, --delete Delete a OBJECT record NAME
-m, --modify Modify a OBJECT record NAME
-l, --list List the OBJECTS
-h, --help Display this message
-n, --noheading Do not print heading when listing OBJECTS
Object-specific Options (see above):
-f, --ftype File Type of OBJECT
"" (all files)
-- (regular file)
-d (directory)
-c (character device)
-b (block device)
-s (socket)
-l (symbolic link)
-p (named pipe)
-p, --proto Port protocol (tcp or udp)
-P, --prefix Prefix for home directory labeling
-L, --level Default SELinux Level (MLS/MCS Systems only)
-R, --roles SELinux Roles (ex: "sysadm_r staff_r")
-T, --trans SELinux Level Translation (MLS/MCS Systems only)
-s, --seuser SELinux User Name
-t, --type SELinux Type for the object
-r, --range MLS/MCS Security Range (MLS/MCS Systems only)
On inspection, there is no file or directory named "/usr/lib/libGL"
or "/usr/lib/libGL(core)"
# /usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t
'/usr/lib/libnvidia.*\.so(\.[^/]*)*'
Running this command yielded similar results as just above, and in this case
there is no file/directory named "/usr/lib/libnvidia" - the same for the next
command
# /sbin/restorecon -v /usr/lib/libGL* /usr/lib/libnvidia*
In case of line wrapping, each of the three commands above should be on
a single line.
The above is based upon a discussion with Paul Howarth on the SELinux list
I'm running the nvidia rpms from Livna - there is a folder
called "/usr/lib/nvidia" which has "*.so" files in it; could this be
what you
mean for the last two commands? That still wouldn't account for the problem
with "/usr/lib/libGL", however...
--
Claude Jones
Brunswick, MD, USA
8:14 a.m.
Claude Jones wrote:
On Tuesday August 01 2006 8:20 am, Marc Schwartz wrote:
Marc: comments interspersed
> Just a heads up. If you do want to use the nVidia installer with SELinux
> enabled, the instructions on the FedoraFaq web site need to be updated.
The changes I suggested on f-s-l were to avoid globally allowing
execstack/execmod, and limiting this to those objects that actually
needed it. The approach suggested in fedorafaq works, but could be more
securely done.
> Undo the changes to the booleans:
>
> # /usr/sbin/setsebool -P allow_execstack 0
> # /usr/sbin/setsebool -P allow_execmod 0
>
ran these and immediately got a prompt with no messages
> Then update the file contexts instead:
>
> # /usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t
> '/usr/lib/libGL(core)?\.so(\.[^/]*)*'
Running each of the next three produced readout that seemed to indicate errors
in syntax - i.e. instructions for proper running of the command:
/usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t'/usr/lib/libGL(core)?
\.so(\.[^/]*)*'
semanage {login|user|port|interface|fcontext|translation} -l [-n]
semanage login -{a|d|m} [-sr] login_name
semanage user -{a|d|m} [-LrRP] selinux_name
semanage port -{a|d|m} [-tr] [ -p protocol ] port | port_range
semanage interface -{a|d|m} [-tr] interface_spec
semanage fcontext -{a|d|m} [-frst] file_spec
semanage translation -{a|d|m} [-T] level
Space missing between textrel_shlib_t and
'/usr/lib/libGL(core)?\.so(\.[^/]*)*'
> # /usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t
> '/usr/lib/libnvidia.*\.so(\.[^/]*)*'
Running this command yielded similar results as just above, and in this case
there is no file/directory named "/usr/lib/libnvidia" - the same for the next
command
> # /sbin/restorecon -v /usr/lib/libGL* /usr/lib/libnvidia*
>
> In case of line wrapping, each of the three commands above should be on
> a single line.
>
> The above is based upon a discussion with Paul Howarth on the SELinux list
I'm running the nvidia rpms from Livna - there is a folder
called "/usr/lib/nvidia" which has "*.so" files in it; could this be
what you
mean for the last two commands? That still wouldn't account for the problem
with "/usr/lib/libGL", however...
The advice I gave to Mark was based on his use of the nvidia installer
directly; the file contexts for a properly-packaged RPM like the one
from livna will be different because the files will be somewhere else
(and the context fixes might even be done in the RPM itself; I don't know).
Paul.
8:22 a.m.
On Tuesday August 01 2006 9:14 am, Paul Howarth wrote:
The advice I gave to Mark was based on his use of the nvidia
installer
directly; the file contexts for a properly-packaged RPM like the one
from livna will be different because the files will be somewhere else
(and the context fixes might even be done in the RPM itself; I don't know).
I'm trying to troubleshoot a couple of problems with software packages, and
I'm in a bit over my head. The problems are with the game ppracer and with
Jahshaka, the video editing package. In both cases, they depend on GL - in
both cases, the programs initiate seemingly normally, then quit without any
error messages. Jahshaka just shuts down immediately after display of the
splash screen. Ppracer gives you its menus but shuts down as soon as you try
to initiate a game...
--
Claude Jones
Brunswick, MD, USA
8:26 a.m.
Claude Jones wrote:
On Tuesday August 01 2006 9:14 am, Paul Howarth wrote:
> The advice I gave to Mark was based on his use of the nvidia installer
> directly; the file contexts for a properly-packaged RPM like the one
> from livna will be different because the files will be somewhere else
> (and the context fixes might even be done in the RPM itself; I don't know).
I'm trying to troubleshoot a couple of problems with software packages, and
I'm in a bit over my head. The problems are with the game ppracer and with
Jahshaka, the video editing package. In both cases, they depend on GL - in
both cases, the programs initiate seemingly normally, then quit without any
error messages. Jahshaka just shuts down immediately after display of the
splash screen. Ppracer gives you its menus but shuts down as soon as you try
to initiate a game...
If you put SELinux in permissive mode:
# setenforce 0
and the problem still persists, then it's probably not an SELinux issue.
You can re-enter enforcing mode using:
# setenforce 1
Paul.
8:40 a.m.
On Tuesday August 01 2006 9:26 am, Paul Howarth wrote:
If you put SELinux in permissive mode:
# setenforce 0
and the problem still persists, then it's probably not an SELinux issue.
You can re-enter enforcing mode using:
# setenforce 1
setenforce 0 fixes the issue, which is why I figure it's Selinux
--
Claude Jones
Brunswick, MD, USA
8:52 a.m.
Claude Jones wrote:
On Tuesday August 01 2006 9:26 am, Paul Howarth wrote:
> If you put SELinux in permissive mode:
>
> # setenforce 0
>
> and the problem still persists, then it's probably not an SELinux issue.
>
> You can re-enter enforcing mode using:
>
> # setenforce 1
setenforce 0 fixes the issue, which is why I figure it's Selinux
OK, let's fix this.
# setenforce 0
Run the troublesome app.
Look in /var/log/messages for SELinux AVC denials since the "setenforce"
was done. Post what you get.
Paul.
12:08 p.m.
On Tue August 1 2006 9:52 am, Paul Howarth wrote:
OK, let's fix this.
# setenforce 0
Run the troublesome app.
Look in /var/log/messages for SELinux AVC denials since the
"setenforce" was done. Post what you get.
OK - I'll do it as soon as I get home - be about 7 hours from
when this gets posted
--
Claude Jones
Brunswick, Md, USA
10:08 p.m.
On Tuesday August 01 2006 9:52 am, Paul Howarth wrote:
> setenforce 0 fixes the issue, which is why I figure it's
Selinux
OK, let's fix this.
# setenforce 0
Run the troublesome app.
Look in /var/log/messages for SELinux AVC denials since the "setenforce"
was done. Post what you get.
Finally getting a chance to do this:
If I setenforce 0, both programs run, but Jahshaka only will run as root.
Neither produces any messages in /var/log/messages - Jahshaka produces this
on the cli:
# jahshaka
jahshaka.bin: error while loading shared libraries: libGL.so.1: cannot enable
executable stack as shared object requires: Permission denied
If I setenforce 1, neither program runs - right about that time, I get the
following in /var/log/messages:
Aug 1 23:02:39 tehogee automount[15231]: >> /usr/sbin/showmount: can't get
address for .directory
Aug 1 23:02:39 tehogee automount[15231]: lookup(program): lookup
for .directory failed
Aug 1 23:02:39 tehogee automount[15231]: failed to mount /net/.directory
Those get repeated about 8 times.
--
Claude Jones
Brunswick, MD, USA
10:46 p.m.
On Tuesday August 01 2006 11:08 pm, Claude Jones wrote:
> Look in /var/log/messages for SELinux AVC denials since the
"setenforce"
> was done. Post what you get.
I'm reading the Fedora Selinux docs and saw this "File context are stored with
the Inode in an extended attribute on systems that support extended
attributes. This works the same way as DAC Protections and ACL's. In that the
security of the file is based information stored at the Inode not the path to
the file."
Looking at /var/log/messages I notice that I'm getting a ton of these:
Aug 1 23:08:42 tehogee kernel: inode_doinit_with_dentry:
context_to_sid(user_u:object_r:unconfined_var_tmp_t) returned 22 for dev=dm-0
ino=9527355
Aug 1 23:08:42 tehogee kernel: inode_doinit_with_dentry:
context_to_sid(user_u:object_r:unconfined_var_tmp_t) returned 22 for dev=dm-0
ino=9528591
Aug 1 23:08:42 tehogee kernel: inode_doinit_with_dentry:
context_to_sid(user_u:object_r:unconfined_var_tmp_t) returned 22 for dev=dm-0
ino=9528590
Aug 1 23:08:42 tehogee kernel: inode_doinit_with_dentry:
context_to_sid(user_u:object_r:unconfined_var_tmp_t) returned 22 for dev=dm-0
ino=9528592
Aug 1 23:08:42 tehogee kernel: inode_doinit_with_dentry:
context_to_sid(user_u:object_r:unconfined_var_tmp_t) returned 22 for dev=dm-0
ino=9528588
Aug 1 23:08:42 tehogee kernel: inode_doinit_with_dentry:
context_to_sid(user_u:object_r:unconfined_var_tmp_t) returned 22 for dev=dm-0
ino=952858
There are over a hundred of these over the course of the day, including a
bunch since I tried to run those programs. I don't know the relevance, but, I
post them in case...
--
Claude Jones
Brunswick, MD, USA
1:17 p.m.
On Tue, 2006-08-01 at 23:08 -0400, Claude Jones wrote:
On Tuesday August 01 2006 9:52 am, Paul Howarth wrote:
> > setenforce 0 fixes the issue, which is why I figure it's Selinux
>
> OK, let's fix this.
>
> # setenforce 0
>
> Run the troublesome app.
>
> Look in /var/log/messages for SELinux AVC denials since the "setenforce"
> was done. Post what you get.
Finally getting a chance to do this:
If I setenforce 0, both programs run, but Jahshaka only will run as root.
Neither produces any messages in /var/log/messages -
Perhaps you have auditd running (this was the default on FC4). If so,
the AVC messages will be in /var/log/audit/audit.log
Jahshaka produces this
on the cli:
# jahshaka
jahshaka.bin: error while loading shared libraries: libGL.so.1: cannot enable
executable stack as shared object requires: Permission denied
If you know which libGL.so.1 this is, you could try:
# execstack -c /path/to/libGL.so.1
If I setenforce 1, neither program runs - right about that time, I
get the
following in /var/log/messages:
Aug 1 23:02:39 tehogee automount[15231]: >> /usr/sbin/showmount: can't get
address for .directory
Aug 1 23:02:39 tehogee automount[15231]: lookup(program): lookup
for .directory failed
Aug 1 23:02:39 tehogee automount[15231]: failed to mount /net/.directory
Those get repeated about 8 times.
Might not be related. We'll see. See if you can find any type=AVC
messages in /var/log/audit/audit.log.
Paul.
6:35 p.m.
On Wed August 2 2006 2:17 pm, Paul Howarth wrote:
Perhaps you have auditd running (this was the default on FC4).
If so, the AVC messages will be in /var/log/audit/audit.log
I do, and I found that just before I left home this am.
I'll poke around those avc messages when I get back.
> Jahshaka produces this
> on the cli:
>
> # jahshaka
> jahshaka.bin: error while loading shared libraries:
> libGL.so.1: cannot enable executable stack as shared object
> requires: Permission denied
If you know which libGL.so.1 this is, you could try:
# execstack -c /path/to/libGL.so.1
OK - I'll give that a try, too - come to think about it, that's a
lib that gave me some trouble a few days back...I'm going to
have to revisit that, and remember what it was about, and what
the fix was...
> If I setenforce 1, neither program runs - right about that
> time, I get the following in /var/log/messages:
>
> Aug 1 23:02:39 tehogee automount[15231]: >>
> /usr/sbin/showmount: can't get address for .directory
> Aug 1 23:02:39 tehogee automount[15231]: lookup(program):
> lookup for .directory failed
> Aug 1 23:02:39 tehogee automount[15231]: failed to mount
> /net/.directory
>
> Those get repeated about 8 times.
Might not be related. We'll see. See if you can find any
type=AVC messages in /var/log/audit/audit.log.
OK - it'll be about 4 hours till I get back to that
machine...thanks for your suggestions
--
Claude Jones
Brunswick, Md, USA
11:57 p.m.
On Wednesday August 02 2006 7:35 pm, Claude Jones wrote:
Paul: On further experimenting this evening, I find that I had things all
wrong - see below
On Wed August 2 2006 2:17 pm, Paul Howarth wrote:
> Perhaps you have auditd running (this was the default on FC4).
> If so, the AVC messages will be in /var/log/audit/audit.log
I do, and I found that just before I left home this am.
I'll poke around those avc messages when I get back.
I've looked through the audit messages. The ones that raise alarms mostly seem
to pertain to kio operations related to images embedded in emails. Nothing
there to indicate any issues with my two programs. Here's an example:
type=AVC msg=audit(1154571140.444:1802): avc: denied { associate } for
pid=8552 comm="kio_http"
name="www.corasworks.net_graphics_EmailTemplates_BlueEmailOriginalVersion_whitepaper.gif_6ffce860.new"
scontext=user_u:object_r:unlabeled_t:s0 tcontext=system_u:o>
> > Jahshaka produces this
> > on the cli:
> >
> > # jahshaka
> > jahshaka.bin: error while loading shared libraries:
> > libGL.so.1: cannot enable executable stack as shared object
> > requires: Permission denied
>
> If you know which libGL.so.1 this is, you could try:
>
> # execstack -c /path/to/libGL.so.1
OK - I'll give that a try, too - come to think about it, that's a
lib that gave me some trouble a few days back...I'm going to
have to revisit that, and remember what it was about, and what
the fix was...
A few days ago, there was an issue with new ATI drivers borking libGL - it's
referred to here: http://tinyurl.com/mnx8o
That's what I was trying to remember. That fix cured my ATI problem, but
that's on my machine at work - this box has an NVidia card, so scratch that
theory...
By the way, I can't repeat that libGL.so.1 error this evening - as user if I
run jahshaka tonight, I get:
$ jahshaka
QObject::connect: No such signal FigureEditor::updateFrameOffset(assetData)
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
and if I switch to root, it runs, and the cli output is:
$ su -$ su -
Password:
[root@tehogee ~]# jahshaka
QObject::connect: No such signal FigureEditor::updateFrameOffset(assetData)
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
QWidget::setMinimumSize: The smallest allowed size is (0,0)
QWidget::setMinimumSize: The smallest allowed size is (0,0)
QWidget::setMinimumSize: The smallest allowed size is (0,0)
QObject::connect: No such slot JahControl::slotSaveSceneAs()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
QObject::connect: No such slot JahControl::SceneAppendScene()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
QObject::connect: No such slot JahControl::ExportMedia()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
QObject::connect: No such slot JahControl::PackageSaveScene()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
Password:
[root@tehogee ~]# jahshaka
QObject::connect: No such signal FigureEditor::updateFrameOffset(assetData)
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
QWidget::setMinimumSize: The smallest allowed size is (0,0)
QWidget::setMinimumSize: The smallest allowed size is (0,0)
QWidget::setMinimumSize: The smallest allowed size is (0,0)
QObject::connect: No such slot JahControl::slotSaveSceneAs()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
QObject::connect: No such slot JahControl::SceneAppendScene()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
QObject::connect: No such slot JahControl::ExportMedia()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
QObject::connect: No such slot JahControl::PackageSaveScene()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: 'unnamed')
Doesn't seem like a selinux issue to me - do you agree?
> > If I setenforce 1, neither program runs - right about that
> > time, I get the following in /var/log/messages:
> >
> > Aug 1 23:02:39 tehogee automount[15231]: >>
> > /usr/sbin/showmount: can't get address for .directory
> > Aug 1 23:02:39 tehogee automount[15231]: lookup(program):
> > lookup for .directory failed
> > Aug 1 23:02:39 tehogee automount[15231]: failed to mount
> > /net/.directory
> >
> > Those get repeated about 8 times.
>
> Might not be related. We'll see. See if you can find any
> type=AVC messages in /var/log/audit/audit.log.
This turns out to not be true - PPRacer is running just fine this evening with
setenforce 1 - Jahshaka only runs as root, and that has nothing to do with
whether selinux is enforcing or not -
bottom line - sorry for the noise
--
Claude Jones
Brunswick, MD, USA
12:02 a.m.
On Thu, 2006-08-03 at 00:57 -0400, Claude Jones wrote:
Jahshaka
Where did you get that package? Yum knows not of it. Ric
--
================================================
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
...the Sin of Ignorance, and
...the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
Sign up at: http://counter.li.org/
http://www.sourceforge.net/projects/oar
http://www.wayward4now.net
================================================
12:14 a.m.
On Monday August 07 2006 1:02 am, Ric Moore wrote:
> Jahshaka
Where did you get that package? Yum knows not of it. Ric
http://tinyurl.com/q4gon
scroll about half way down and they have instrux for installing their repo for
FC5
--
Claude Jones
Brunswick, MD, USA
12:06 a.m.
On Thu, 2006-08-03 at 00:57 -0400, Claude Jones wrote:
On Wednesday August 02 2006 7:35 pm, Claude Jones wrote:
Paul: On further experimenting this evening, I find that I had things all
wrong - see below
Just go here and you'll get it all right... Stanton does a heckuva job.
Check it out:
http://www.stanton-finley.net/fedora_core_5_installation_notes.html#nVidia
Nary a burp in the barrel. Works flawlessly. Ric
--
================================================
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
...the Sin of Ignorance, and
...the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
Sign up at: http://counter.li.org/
http://www.sourceforge.net/projects/oar
http://www.wayward4now.net
================================================
12:18 a.m.
On Monday August 07 2006 1:06 am, Ric Moore wrote:
Just go here and you'll get it all right... Stanton does a
heckuva job.
Check it out:
http://www.stanton-finley.net/fedora_core_5_installation_notes.html#nVidia
Nary a burp in the barrel. Works flawlessly. Ric
I'm not sure which issue you're referring to, Ric. As far as NVidia goes,
that's working just fine. I use Stanton's site quite a lot, but thanks.
--
Claude Jones
Brunswick, MD, USA
9:21 a.m.
Paul Howarth wrote:
Claude Jones wrote:
> On Tuesday August 01 2006 8:20 am, Marc Schwartz wrote:
> Marc: comments interspersed
>> Just a heads up. If you do want to use the nVidia installer with SELinux
>> enabled, the instructions on the FedoraFaq web site need to be updated.
The changes I suggested on f-s-l were to avoid globally allowing
execstack/execmod, and limiting this to those objects that actually
needed it. The approach suggested in fedorafaq works, but could be more
securely done.
>> Undo the changes to the booleans:
>>
>> # /usr/sbin/setsebool -P allow_execstack 0
>> # /usr/sbin/setsebool -P allow_execmod 0
>>
>
> ran these and immediately got a prompt with no messages
>
>> Then update the file contexts instead:
>>
>> # /usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t
>> '/usr/lib/libGL(core)?\.so(\.[^/]*)*'
>
> Running each of the next three produced readout that seemed to
> indicate errors in syntax - i.e. instructions for proper running of
> the command:
>
> /usr/sbin/semanage fcontext -a -f -- -t
> textrel_shlib_t'/usr/lib/libGL(core)?
> \.so(\.[^/]*)*'
> semanage {login|user|port|interface|fcontext|translation} -l [-n]
> semanage login -{a|d|m} [-sr] login_name
> semanage user -{a|d|m} [-LrRP] selinux_name
> semanage port -{a|d|m} [-tr] [ -p protocol ] port | port_range
> semanage interface -{a|d|m} [-tr] interface_spec
> semanage fcontext -{a|d|m} [-frst] file_spec
> semanage translation -{a|d|m} [-T] level
Space missing between textrel_shlib_t and
'/usr/lib/libGL(core)?\.so(\.[^/]*)*'
>> # /usr/sbin/semanage fcontext -a -f -- -t textrel_shlib_t
>> '/usr/lib/libnvidia.*\.so(\.[^/]*)*'
>
> Running this command yielded similar results as just above, and in
> this case there is no file/directory named "/usr/lib/libnvidia" - the
> same for the next command
>
>> # /sbin/restorecon -v /usr/lib/libGL* /usr/lib/libnvidia*
>>
>> In case of line wrapping, each of the three commands above should be on
>> a single line.
>>
>> The above is based upon a discussion with Paul Howarth on the SELinux
>> list
>
> I'm running the nvidia rpms from Livna - there is a folder called
> "/usr/lib/nvidia" which has "*.so" files in it; could this be
what you
> mean for the last two commands? That still wouldn't account for the
> problem with "/usr/lib/libGL", however...
The advice I gave to Mark was based on his use of the nvidia installer
directly; the file contexts for a properly-packaged RPM like the one
from livna will be different because the files will be somewhere else
(and the context fixes might even be done in the RPM itself; I don't know).
Paul.
Paul,
Thanks for replying here. I was in transit between home and office when
Claude's post came through.
Marc
5:19 a.m.
jbuck814366460(a)aol.com wrote:
Hi all,
I'm following the FedoraFAQ.org instructions for installing the NVDIA
drivers and two of the commands given for getting the drivers up and
running don't work.
I'm entering
setsebool -P allow_execmod=1
but bash says the command is not found. Same with "init 3" for
bringing FC5 down to the command line so i can enable the drivers.
I've been running both commands as root user with "su" and as a
regular user, but neither work. Any help here?
[ito]
When switching to root user, use "su -" instead of "su" so you will
get
the root environment variables that should help you with the missing
commands in the PATH.
Jared
------------------------------------------------------------------------
*Check out AOL.com today*
<http://pr.atwola.com/promoclk/1615326657x4311227241x4298082137/aol?redir=...;.
Breaking news, video search, pictures, email and IM. All on demand.
Always Free.
--
Best regards,
*Ketut Mahaindra (Ito)*
///"The race for perfection has no finish line"/
8:06 a.m.
On Tue, 2006-08-01 at 06:08 -0400, jbuck814366460(a)aol.com wrote:
Hi all,
I'm following the FedoraFAQ.org instructions for installing the NVDIA
drivers and two of the commands given for getting the drivers up and
running don't work.
I'm entering
setsebool -P allow_execmod=1
but bash says the command is not found. Same with "init 3" for
bringing FC5 down to the command line so i can enable the drivers.
I've been running both commands as root user with "su" and as a
regular user, but neither work. Any help here?
try "su -" so you have the root environment.
Jared
______________________________________________________________________
Check out AOL.com today. Breaking news, video search, pictures, email
and IM. All on demand. Always Free.
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
6512
days inactive
6518
days old
21 comments
8 participants
participants (8)
-
Claude Jones -
jbuck814366460＠aol.com -
Jeff Vian -
Ketut Mahaindra -
Marc Schwartz -
Paul F. Johnson -
Paul Howarth -
Ric Moore