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] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 10 Nov 2018 04:43:08 +0000
From:   chouryzhou(周威) <chouryzhou@...cent.com>
To:     tkjos <tkjos@...gle.com>
CC:     gregkh <gregkh@...uxfoundation.org>, arve <arve@...roid.com>,
        tkjos <tkjos@...roid.com>, akpm <akpm@...ux-foundation.org>,
        dave <dave@...olabs.net>, devel <devel@...verdev.osuosl.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        chouryzhou <chouryzhou@...il.com>
Subject: Re: Re: [PATCH V3] binder: ipc namespace support for android
 binder(Internet mail)


> > > I still don't understand the dependencies on SYSVIPC or POSIX_MQUEUE.
> > > It seems like this mechanism would work even if both are disabled --
> > > as long as IPC_NS is enabled. Seems cleaner to change init/Kconfig and
> > > allow IPC_NS if CONFIG_ANDROID_BINDER_IPC and change this line to
> > > "#ifndef CONFIG_IPC_NS"
> >
> > Let me explain it in detail. If SYSIPC and IPC_NS are both defined,
> > current->nsproxy->ipc_ns will save the ipc namespace variables. We just use
> > it. If SYSIPC (or POSIX_MQUEUE) is defined while IPC_NS is not set,
> > current->nsproxy->ipc_ns will always refer to init_ipc_ns in ipc/msgutil.c,
> > which is also fine to us. But if neither SYSIPC nor POSIX_MQUEUE is set
> > (IPC_NS can't be set in this situation), there is no current->nsproxy->ipc_ns.
> > We make a fack init_ipc_ns here and use it.
> 
> Yes, I can read the code. I'm wondering specifically about SYSVIPC and
> POSIX_MQUEUE. Even with your code changes, binder has no dependency on
> these configs. Why are you creating one? The actual dependency with
> your changes is on "current->nsproxy->ipc_ns" being initialized for
> binder -- which is dependent on CONFIG_IPC_NS being enabled, isn't it?
> 
> If SYSVIPC or POSIX_MQUEUE are enabled, but IPC_NS is disabled, does this work? 

If IPC_NS is disabled, "current-nsporxy->ipc_ns" will also exists,  it will be a static 
reference of "init_ipc_ns" (in ipc/msgutil.c, not defined in binder.c by me) with 
no namespace-ization. You will get the same one in all processes, everything is 
the same as  without this patch.

- choury -

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ