On 07/21/2015 06:49 AM, Daniel J Walsh wrote:
On 07/20/2015 03:49 PM, jd1008 wrote:
On 07/20/2015 01:42 PM, Martin Cigorraga wrote:
Hi,
~ getenforce
Enforcing
Please be aware that setenforce will only change the mode SELinux is
running in. For a permanent change, you have to edit the
confi
On 07/21/2015 06:49 AM, Daniel J Walsh wrote:
On 07/20/2015 03:49 PM, jd1008 wrote:
On 07/20/2015 01:42 PM, Martin Cigorraga wrote:
Hi,
~ getenforce
Enforcing
Please be aware that setenforce will only change the mode SELinux is
running in. For a permanent change, you have to edit the
confi
You can just run
# restorecon -R -v /
From the booted machine.
On 07/20/2015 03:49 PM, jd1008 wrote:
>
>
> On 07/20/2015 01:42 PM, Martin Cigorraga wrote:
>> Hi,
>>
>> ~ getenforce
>> Enforcing
>>
>> Please be aware that setenforce will only change the mode SELinux is
>> running in. For a perman
On 07/20/2015 01:42 PM, Martin Cigorraga wrote:
Hi,
~ getenforce
Enforcing
Please be aware that setenforce will only change the mode SELinux is
running in. For a permanent change, you have to edit the configuration
file.
I already stated that /etc/sysconfig/selinux says (and did say whe
Hi,
~ getenforce
Enforcing
Please be aware that setenforce will only change the mode SELinux is
running in. For a permanent change, you have to edit the configuration file.
On Mon, Jul 20, 2015 at 4:32 PM jd1008 wrote:
>
>
> On 07/20/2015 12:38 PM, Martin Cigorraga wrote:
> > Hi,
> >
> > I cre
On 07/20/2015 12:38 PM, Martin Cigorraga wrote:
Hi,
I created the file /.autorelabel (# touch /.autorelabel), set SELinux
to 'enforcing' and (/etc/sysconfig/selinux) and rebooted.
May be I could do it without rebooting as stated in this question:
https://serverfault.com/questions/453137/ho
On 07/20/2015 12:38 PM, Martin Cigorraga wrote:
> I created the file /.autorelabel (# touch /.autorelabel), set SELinux
to 'enforcing' and (/etc/sysconfig/selinux) and rebooted.
>
> May be I could do it without rebooting as stated in this question:
https://serverfault.com/questions/453137/how
Hi,
I created the file /.autorelabel (# touch /.autorelabel), set SELinux to
'enforcing' and (/etc/sysconfig/selinux) and rebooted.
May be I could do it without rebooting as stated in this question:
https://serverfault.com/questions/453137/how-can-i-do-an-selinux-filesystem-relabel-without-reboot
On 07/20/2015 12:23 PM, Martin Cigorraga wrote:
Hello folks,
It happened to me too that about a week or so ago SELinux
automatically turned to 'Permissive' with an upgrade of
selinux-related packages, I had to relabel everything to get things
back to its previous state.
Although I didn't
Hello folks,
It happened to me too that about a week or so ago SELinux automatically
turned to 'Permissive' with an upgrade of selinux-related packages, I had
to relabel everything to get things back to its previous state.
Although I didn't delve in the issue at that moment I will keep an eye on
On 07/20/2015 10:58 AM, jd1008 wrote:
On 07/20/2015 11:50 AM, Joe Zeff wrote:
On 07/20/2015 10:45 AM, jd1008 wrote:
But I did not set it into permissive mode. I finished installing it
mid-day yesterday,
Why did you install a version that you knew was past EOL?
For confidential apps I have
On 07/20/2015 11:57 AM, Gordon Messmer wrote:
On 07/20/2015 10:47 AM, jd1008 wrote:
So, how did it become permissive??
We have no way to answer that. Your audit log would record the time
at which the system entered permissive mode.
How incredibly mysterious is that?
here are a few of the
On 07/20/2015 11:50 AM, Joe Zeff wrote:
On 07/20/2015 10:45 AM, jd1008 wrote:
But I did not set it into permissive mode. I finished installing it
mid-day yesterday,
Why did you install a version that you knew was past EOL?
For confidential apps I have no source for, only binaries which dema
On 07/20/2015 10:47 AM, jd1008 wrote:
So, how did it become permissive??
We have no way to answer that. Your audit log would record the time at
which the system entered permissive mode.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https:/
On 07/20/2015 10:45 AM, jd1008 wrote:
But I did not set it into permissive mode. I finished installing it
mid-day yesterday,
Why did you install a version that you knew was past EOL?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin
On 07/20/2015 11:43 AM, Gordon Messmer wrote:
On 07/20/2015 09:44 AM, jd1008 wrote:
Source RPM Packages python-2.7.5-16.fc20.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.12.1-197.fc20.noarch
Fedora 20 is EOL. There will be no further updates. Troubleshooting
policy errors in outd
On 07/20/2015 11:43 AM, Gordon Messmer wrote:
On 07/20/2015 09:44 AM, jd1008 wrote:
Source RPM Packages python-2.7.5-16.fc20.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.12.1-197.fc20.noarch
Fedora 20 is EOL. There will be no further updates. Troubleshooting
policy errors in outd
On 07/20/2015 09:44 AM, jd1008 wrote:
Source RPM Packages python-2.7.5-16.fc20.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.12.1-197.fc20.noarch
Fedora 20 is EOL. There will be no further updates. Troubleshooting
policy errors in outdated packages is largely a waste of tim
On 07/19/2015 08:27 PM, Ed Greshko wrote:
On 07/20/15 09:39, jd1008 wrote:
I forgot the file I touch in / to force a relabel, something like
.relabel=true ???
touch /.autorelabel google would have found that for you.
Yep! I found it in a fedoraproject forum message
right after I sent the em
On 07/20/15 09:39, jd1008 wrote:
>
> I forgot the file I touch in / to force a relabel, something like
> .relabel=true ???
>
touch /.autorelabel
google would have found that for you.
--
If I wanted a blog or social media I'd go elsewhere
--
users mailing list
users@lists.fedoraproject.org
To
On 07/19/2015 07:00 PM, Ed Greshko wrote:
On 07/20/15 08:47, jd1008 wrote:
On 07/19/2015 05:45 PM, Ed Greshko wrote:
On 07/20/15 07:31, jd1008 wrote:
On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
If they are enabled, disable them for the time being and che
On 07/20/15 08:47, jd1008 wrote:
>
>
> On 07/19/2015 05:45 PM, Ed Greshko wrote:
>> On 07/20/15 07:31, jd1008 wrote:
>>>
>>> On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
> If they are enabled, disable them for the time being and check to see if
> the
On 07/19/2015 05:45 PM, Ed Greshko wrote:
On 07/20/15 07:31, jd1008 wrote:
On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
If they are enabled, disable them for the time being and check to see if the
sealerts cease.
I should have said "stop" and "disable" th
On 07/20/15 07:31, jd1008 wrote:
>
>
> On 07/18/2015 09:18 PM, Ed Greshko wrote:
>> On 07/19/15 11:12, Ed Greshko wrote:
>>> If they are enabled, disable them for the time being and check to see if
>>> the sealerts cease.
>> I should have said "stop" and "disable" them.
>>
> Done! and problem solv
On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
If they are enabled, disable them for the time being and check to see if the
sealerts cease.
I should have said "stop" and "disable" them.
Done! and problem solved!!!
Thanx a lot!!!
Much appreciated!!!
--
users
On 07/18/2015 09:11 PM, Joe Zeff wrote:
On 07/18/2015 08:02 PM, jd1008 wrote:
egid=0 sgid=0 fsgid=0 ses=37 tty=(none) comm=sa1 exe=/usr/bin/sh
subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023
Right there's you're answer: /usr/bin/sh, AKA bash.
Well, who, or more exactly, what is forking a ba
On 07/19/15 11:26, inode0 wrote:
> sa1 appears to be the culprit. It is normally run from a cronjob
> typically every 10 minutes.
See my other message
[root@meimei ~]# systemctl is-enabled sysstat-collect.timer
enabled
[root@meimei ~]# systemctl is-enabled sysstat.service
enabled
If they are
On Sat, Jul 18, 2015 at 10:02 PM, jd1008 wrote:
>
>
> On 07/18/2015 08:46 PM, Ed Greshko wrote:
>>
>> On 07/19/15 10:17, jd1008 wrote:
>>>
>>> The original I posted says:
>>>
>>> type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat
>>> success=no exit=EACCES a0=ff9c a
On 07/19/15 11:12, Ed Greshko wrote:
> If they are enabled, disable them for the time being and check to see if the
> sealerts cease.
I should have said "stop" and "disable" them.
--
If I wanted a blog or social media I'd go elsewhere
--
users mailing list
users@lists.fedoraproject.org
To unsu
On 07/19/15 10:57, jd1008 wrote:
> It is gosh darned fast
> Like every 2 minutes.
>
> $ sudo systemctl -l | grep sysstat
> sysstat.service loaded active exitedResets System Activity Logs
Sorry I wasn't explicit
[root@meimei ~]# systemctl is-enabled sysstat-collect.timer
enabled
[roo
On 07/18/2015 08:02 PM, jd1008 wrote:
egid=0 sgid=0 fsgid=0 ses=37 tty=(none) comm=sa1 exe=/usr/bin/sh
subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023
Right there's you're answer: /usr/bin/sh, AKA bash.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription op
On 07/18/2015 08:46 PM, Ed Greshko wrote:
On 07/19/15 10:17, jd1008 wrote:
The original I posted says:
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat
success=no exit=EACCES a0=ff9c a1=4fcb93 a2=80800 a3=0 items=0
ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid
On 07/18/2015 08:46 PM, Ed Greshko wrote:
On 07/19/15 10:17, jd1008 wrote:
The original I posted says:
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat
success=no exit=EACCES a0=ff9c a1=4fcb93 a2=80800 a3=0 items=0
ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid
On 07/19/15 10:17, jd1008 wrote:
> The original I posted says:
>
> type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat
> success=no exit=EACCES a0=ff9c a1=4fcb93 a2=80800 a3=0 items=0
> ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsg
On 07/18/2015 08:20 PM, Ed Greshko wrote:
On 07/19/15 10:15, jd1008 wrote:
Well, now, this is interesting:
$ sudo ls -l -i -R /root | grep 47972353< Produced no output
$ sudo ls -l -d -i -R /root | grep 47972353 << adding the -d option,
however:
47972353 dr-xr-x---. 9 root root 4
On 07/19/15 10:15, jd1008 wrote:
> Well, now, this is interesting:
>
> $ sudo ls -l -i -R /root | grep 47972353< Produced no output
> $ sudo ls -l -d -i -R /root | grep 47972353 << adding the -d option,
> however:
> 47972353 dr-xr-x---. 9 root root 4096 Jul 2 14:03 /root
> $
>
> I rea
On 07/18/2015 08:09 PM, Ed Greshko wrote:
On 07/19/15 09:57, jd1008 wrote:
On 07/18/2015 07:53 PM, Ed Greshko wrote:
On 07/19/15 09:17, jd1008 wrote:
debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
Inode Pathname
47972353//root
So, why is it trying to do that?
I am not logged
On 07/18/2015 08:07 PM, Ed Greshko wrote:
On 07/19/15 09:55, jd1008 wrote:
Ooops, Sorry. Here it is:
$ sudo ls -l -i /* | grep 47972353
OK How about
sudo ls -l -i -R /root | grep 47972353
Well, now, this is interesting:
$ sudo ls -l -i -R /root | grep 47972353< Produced no ou
On 07/19/15 09:57, jd1008 wrote:
>
>
> On 07/18/2015 07:53 PM, Ed Greshko wrote:
>> On 07/19/15 09:17, jd1008 wrote:
>>> debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
>>> Inode Pathname
>>> 47972353//root
>>>
>>> So, why is it trying to do that?
>>> I am not logged in as root.
>>>
>>
On 07/19/15 09:55, jd1008 wrote:
> Ooops, Sorry. Here it is:
> $ sudo ls -l -i /* | grep 47972353
OK How about
sudo ls -l -i -R /root | grep 47972353
--
If I wanted a blog or social media I'd go elsewhere
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscr
On 07/18/2015 07:53 PM, Ed Greshko wrote:
On 07/19/15 09:17, jd1008 wrote:
debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
Inode Pathname
47972353//root
So, why is it trying to do that?
I am not logged in as root.
How can I find out the process(es) that spawned sh
to access /roo
On 07/18/2015 07:53 PM, Ed Greshko wrote:
On 07/19/15 09:51, jd1008 wrote:
On 07/18/2015 07:46 PM, Ed Greshko wrote:
sudo ls -l -i /* | grep 47972353
$ ls -l -i /* | grep 47972353
$
Nop!
And why did you not use "sudo" as shown?
Ooops, Sorry. Here it is:
$ sudo ls -l -i /* | grep 4797235
On 07/19/15 09:17, jd1008 wrote:
> debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
> Inode Pathname
> 47972353//root
>
> So, why is it trying to do that?
> I am not logged in as root.
>
> How can I find out the process(es) that spawned sh
> to access /root?
OK, so you have determined
On 07/19/15 09:51, jd1008 wrote:
>
>
> On 07/18/2015 07:46 PM, Ed Greshko wrote:
>> sudo ls -l -i /* | grep 47972353
> $ ls -l -i /* | grep 47972353
> $
>
> Nop!
And why did you not use "sudo" as shown?
--
If I wanted a blog or social media I'd go elsewhere
--
users mailing list
users@lists.fed
On 07/18/2015 07:46 PM, Ed Greshko wrote:
sudo ls -l -i /* | grep 47972353
$ ls -l -i /* | grep 47972353
$
Nop!
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: htt
On 07/19/15 09:20, jd1008 wrote:
> Also, /dev/sda3 has no dir named root:
>
> $ ls /sda3/root
> /bin/ls: cannot access /sda3/root: No such file or directory
Of course not, since there probably is no /sda3 directory.
Does
sudo ls -l -i /* | grep 47972353
return a filename?
--
If I wanted a
On 07/18/2015 07:10 PM, Ed Greshko wrote:
On 07/19/15 09:00, jd1008 wrote:
The sealert below does not tell me exactly which dir
that the shell tried to access.
I have run the suggested commands (below)
but they did not do any good.
The alerts keep popping up.
SELinux is preventing /usr/bin/
On 07/18/2015 07:10 PM, Ed Greshko wrote:
sudo debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
Inode Pathname
47972353//root
So, why is it trying to do that?
I am not logged in as root.
How can I find out the process(es) that sp
On 07/19/15 09:00, jd1008 wrote:
> The sealert below does not tell me exactly which dir
> that the shell tried to access.
> I have run the suggested commands (below)
> but they did not do any good.
> The alerts keep popping up.
>
>
>
> SELinux is preventing /usr/bin/sh from read access on the direc
The sealert below does not tell me exactly which dir
that the shell tried to access.
I have run the suggested commands (below)
but they did not do any good.
The alerts keep popping up.
SELinux is preventing /usr/bin/sh from read access on the directory .
* Plugin catchall (100. confidence
50 matches
Mail list logo
