Paul Howarth wrote:
On Tue, 2006-05-23 at 17:34 +0200, dragoran wrote:
Paul Howarth wrote:
On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote:
dragoran wrote:
dragoran wrote:
Paul Howarth wrote:
On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
dragoran wrote:
dragoran wrote:
audit(1147793154.831:353): avc: denied { execute_no_trans }
for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
scontext=system_u:system_r:prelink_t:s0
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1147793154.831:354): avc: denied { execute_no_trans }
for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
scontext=system_u:system_r:prelink_t:s0
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1147793155.019:355): avc: denied { execute_no_trans }
for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
scontext=system_u:system_r:prelink_t:s0
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1147793155.447:356): avc: denied { execute_no_trans }
for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
scontext=system_u:system_r:prelink_t:s0
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1147793156.255:357): avc: denied { execute_no_trans }
for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
scontext=system_u:system_r:prelink_t:s0
tcontext=system_u:object_r:lib_t:s0 tclass=file
I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
whats gonig on? is a file misslabeled or is this a policy bug?
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
hello?
any solution for this problem?
it happend again...
am I the only one seeing this?
audit(1148393411.538:2907): avc: denied { execute_no_trans } for
pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939
scontext=system_u:system_r:prelink_t:s0
tcontext=system_u:object_r:lib_t:s0 tclass=file
audit(1148393411.794:2908): avc: denied { execmod } for
pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0
ino=29797475 scontext=system_u:system_r:prelink_t:s0
tcontext=root:object_r:lib_t:s0 tclass=file
audit(1148393411.814:2909): avc: denied { execmod } for
pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762"
dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0
tcontext=root:object_r:lib_t:s0 tclass=file
audit(1148393412.438:2910): avc: denied { unlink } for pid=13702
comm="prelink" name="prelink.cache" dev=md0 ino=7012828
scontext=system_u:system_r:prelink_t:s0
tcontext=user_u:object_r:etc_t:s0 tclass=file
prelink seems to be completly broken and nobody seems to notice it?
I'm not seeing this anywhere.
Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on
your
system?
Paul.
ls -Z /lib/ld-2.4.so
-rwxr-xr-x root root system_u:object_r:ld_so_t
/lib/ld-2.4.so
ls -Z /lib64/ld-2.4.so
-rwxr-xr-x root root system_u:object_r:lib_t
seems that you are correct lets hope that this wont happen again.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
this *is* a bug
restorecon /lib64/ld-2.4.so
does not change it to ld_so_t (had to do a chcon)
I did a complete relabel and the result is
ls -Z /lib64/ld-2.4.so
-rwxr-xr-x root root system_u:object_r:lib_t
/lib64/ld-2.4.so
The context line that *should* match this appears to be:
/lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)* regular file
system_u:object_r:ld_so_t:s0
But this appears to be overruled by one of these:
/lib(/.*)? all files
system_u:object_r:lib_t:s0
/lib64(/.*)? all files
system_u:object_r:lib_t:s0
I'm not sure what it is that decides which is the best match. The top
one is longer and appears to me to be more specific, but it does have
more wildcards in it...
I also noticed this:
drwxr-xr-x root root system_u:object_r:bin_t bin
drwxr-xr-x root root system_u:object_r:boot_t boot
drwxr-xr-x root root system_u:object_r:device_t dev
drwxr-xr-x root root system_u:object_r:etc_t etc
drwxr-xr-x root root system_u:object_r:home_root_t home
drwxr-xr-x root root system_u:object_r:lib_t lib
drwxr-xr-x root root system_u:object_r:lib_t lib64
drwx------ root root system_u:object_r:lost_found_t lost+found
drwxr-xr-x root root system_u:object_r:mnt_t media
drwxr-xr-x root root system_u:object_r:mnt_t misc
drwxr-xr-x root root system_u:object_r:mnt_t mnt
dr-xr-xr-x root root system_u:object_r:mnt_t net
drwxr-xr-x root root system_u:object_r:usr_t opt
dr-xr-xr-x root root system_u:object_r:proc_t proc
drwxr-x--- root root root:object_r:user_home_dir_t root
drwxr-xr-x root root system_u:object_r:sbin_t sbin
drwxr-xr-x root root system_u:object_r:security_t selinux
drwxr-xr-x root root system_u:object_r:var_t srv
drwxr-xr-x root root system_u:object_r:sysfs_t sys
drwxrwxrwt root root system_u:object_r:tmp_t tmp
drwxr-xr-x root root system_u:object_r:usr_t usr
drwxr-xr-x root root system_u:object_r:var_t var
looks incorrect too whats going on here?
Looks like mine. What do you think is wrong with this? Nothing stands
out to me.
Paul.
root:object_r:user_home_dir_t root should be /home and
system_u:object_r:home_root_t home should be /root something weird is going on here...
I disagree. I think these are correct.
/root is the home directory for user "root" and should be
user_home_dir_t, just like any other user's home directory.
/home is the root of the "home" directory tree, where most user home
directories live, so home_root_t seems OK for that.
thx got it
Perhaps it's just the names of the context types that are confusing?
yes
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
