lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 08 Jul 2021 21:23:59 +0900
From:   권오훈 <ohoono.kwon@...sung.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        권오훈 <ohoono.kwon@...sung.com>
CC:     "mingo@...nel.org" <mingo@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "christian.brauner@...ntu.com" <christian.brauner@...ntu.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "ohkwon1043@...il.com" <ohkwon1043@...il.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] connector: send event on write to /proc/[pid]/comm

Eric W. Biederman <ebiederm@...ssion.com> writes: 
> 권오훈 <ohoono.kwon@...sung.com> writes:
> > 
> > > While comm change event via prctl has been reported to proc connector by
> > 'commit f786ecba4158 ("connector: add comm change event report to proc
> > connector")', connector listeners were missing comm changes by explicit
> > writes on /proc/[pid]/comm.
> >
> > Let explicit writes on /proc/[pid]/comm report to proc connector.
> 
> Is connector really useful?  I am under the impression that connector
> did not get much if any real uptake of users.
> 
> I know the impression that connector is not used and that there
> are generally better mechanisms for what it provides has led to
> connector not getting any namespace support.  Similarly bugs
> like the one you just have found persist.
> 
> If connector is actually useful then it is worth fixing little things
> like this.  But if no one is really using connector I suspect a better
> patch direction would be to start figuring out how to deprecate and
> remove connector.
> 
> Eric

Dear Eric.

I get your point, and I can also see that /drivers/connector directory has
not been modified since last December, which might imply that not so many
users are actively paying attention to the connector.

However in Samsung, we are currently using connector feature for our
proprietary solution, which uses it to receive kernel events such as fork,
exec, and comm changes at userspace daemon.

Since I am new to patching linux kernel, I cannot say much about whether
connector should be deprecated or not. I guess it is up to all of you guys
who have contributed to the connector driver to discuss and decide.

Meanwhile, I still think bugfixes should be applied until the feature is
actually decided to be deprecated.

Thanks,
Ohhoon Kwon.

> 
> 
> > Signed-off-by: Ohhoon Kwon <ohoono.kwon@...sung.com>
> > ---
> >  fs/proc/base.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index 9cbd915025ad..3e1e6b56aa96 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -95,6 +95,7 @@
> >  #include <linux/posix-timers.h>
> >  #include <linux/time_namespace.h>
> >  #include <linux/resctrl.h>
> > +#include <linux/cn_proc.h>
> >  #include <trace/events/oom.h>
> >  #include "internal.h"
> >  #include "fd.h"
> > @@ -1674,8 +1675,10 @@ static ssize_t comm_write(struct file *file, const char __user *buf,
> >  	if (!p)
> >  		return -ESRCH;
> >  
> > -	if (same_thread_group(current, p))
> > +	if (same_thread_group(current, p)) {
> >  		set_task_comm(p, buffer);
> > +		proc_comm_connector(p);
> > +	}
> >  	else
> >  		count = -EINVAL;


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ