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]
Message-ID: <87lgapwrw4.fsf@xmission.com>
Date:   Thu, 05 Jul 2018 11:48:11 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Christian Brauner <christian@...uner.io>
Cc:     viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, seth.forshee@...onical.com,
        serge@...lyn.com, containers@...ts.linux-foundation.org
Subject: Re: [PATCH] Revert "vfs: Allow userns root to call mknod on owned filesystems."


Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>

Your description is usesless.

It needs to detail exactly what breaks, what regressions and why.
All I see below is hand waving.

We need to know why this does not work so someone does not come in and try
this again.  Or so that someone can fix this and then try again.

You do not include that kind of information in your commit log.

Calling mknod to create device nodes can not be widespread.  There are
not that many privileged processes and calling mknod outside of being
a specialed process like udev is broken.

Therefore I refute your assertion that this is a widespread issue.


I expect somewhere there is a reasonable argument for reverting this
change on the basis that it causes a regression. You have not made it.

Until that time I am going to oppose this revert because your
justfication for the revert is lacking.


It has never been the case that mknod on a device node will guarantee
that you even can open the device node.  The applications that regress
are broken.  It doesn't mean we shouldn't be bug compatible, but we darn
well should document very clearly the bugs we are being bug compatible
with.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ