On Fri, Dec 11, 2020 at 12:29:31PM +0100, Greg KH wrote:
> On Fri, Dec 11, 2020 at 12:46:35PM +0200, Jarkko Sakkinen wrote:
> > On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> > > On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > > > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miet
Good morning;
A question can someone help me with this issue: the file */proc/kcore* has
a size of 140G. How can I fix it, I must restart the server or is there
another way to solve it?
kernel-uek-2.6.39-400.211.1.el6uek
evidence sections:
1.- the size of the kcore file
140737486266368 /proc/kc
On 11.12.2020 12.46, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
On 9.12.2020 2.15, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
As a further argument, I just did this on a Fedora system:
$ find /dev -perm /u
On Wed, Dec 09, 2020 at 10:58:59PM +0100, Ben Hutchings wrote:
> I'm convinced. I've committed a change to initramfs-tools that removes
> the noexec mount option again.
Systemd counterpart: https://github.com/systemd/systemd/pull/17940.
Zbyszek
___
sys
On Fri, Dec 11, 2020 at 12:46:35PM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> > On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > > > As a further argument, I just did thi
On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > > As a further argument, I just did this on a Fedora system:
> > > > > > $ find /dev -perm /ugo+x -a \! -type d
On Wed, Dec 9, 2020 at 11:22 AM Topi Miettinen wrote:
>
> On 9.12.2020 17.14, Andy Lutomirski wrote:
> >
> Maybe also malware which can escape all means of detection, enforced by
> the CPU? Though I don't know if any malware scanners for Linux work can
> check for fileless, memory only malware.
On 9.12.2020 17.14, Andy Lutomirski wrote:
On Dec 9, 2020, at 12:58 AM, Topi Miettinen wrote:
On 9.12.2020 2.42, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
As a further argument, I
> On Dec 9, 2020, at 12:58 AM, Topi Miettinen wrote:
>
> On 9.12.2020 2.42, Jarkko Sakkinen wrote:
>>> On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
>>> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
>>> As a further argument, I just did this on a Fedora
On 9.12.2020 2.42, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
As a further argument, I just did this on a Fedora system:
$ find /dev -perm /ugo+x -a \! -type d -a \! -type l
No results.
On 9.12.2020 2.15, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
As a further argument, I just did this on a Fedora system:
$ find /dev -perm /ugo+x -a \! -type d -a \! -type l
No results. So making /dev noexec doesn't seem to have any benefit.
It's n
On Wed, Dec 09, 2020 at 02:15:28AM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > As a further argument, I just did this on a Fedora system:
> > > > > $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
> > > > > No results. So making /d
On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > As a further argument, I just did this on a Fedora system:
> > > > $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
> > > > No results. So making /dev noexec doesn't seem to have any benefit.
> > >
> > > It's no surprise
On Tue, Dec 08, 2020 at 10:07:17AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote:
> >
> > On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
> > >> Hi udev people-
> > >>
> > >> The
On 8.12.2020 23.30, Andy Lutomirski wrote:
On Dec 8, 2020, at 12:45 PM, Topi Miettinen wrote:
On 8.12.2020 20.07, Andy Lutomirski wrote:
On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote:
On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 19, 2020 at 08:17:08AM -0800
> On Dec 8, 2020, at 12:45 PM, Topi Miettinen wrote:
>
> On 8.12.2020 20.07, Andy Lutomirski wrote:
>>> On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote:
>>>
>>> On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
On 8.12.2020 20.07, Andy Lutomirski wrote:
On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote:
On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
Hi udev people-
The upcoming Linux SGX driver has a device node /dev/sgx
On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen wrote:
>
> On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
> >> Hi udev people-
> >>
> >> The upcoming Linux SGX driver has a device node /dev/sgx. User code
> >> opens it,
On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
Hi udev people-
The upcoming Linux SGX driver has a device node /dev/sgx. User code
opens it, does various setup things, mmaps it, and needs to be able to
create PROT_EXEC m
On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
> Hi udev people-
>
> The upcoming Linux SGX driver has a device node /dev/sgx. User code
> opens it, does various setup things, mmaps it, and needs to be able to
> create PROT_EXEC mappings. This gets quite awkward if /dev is moun
Hi udev people-
The upcoming Linux SGX driver has a device node /dev/sgx. User code
opens it, does various setup things, mmaps it, and needs to be able to
create PROT_EXEC mappings. This gets quite awkward if /dev is mounted
noexec.
Can udev arrange to make a device node executable on distros t
21 matches
Mail list logo