On Fri, Nov 01, 2019 at 12:35:44PM -0700, Andrew Morton wrote:
> On Fri, 1 Nov 2019 12:29:20 -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> > > Either change is an upgrade from the current situation, at least. I prefer
> > > towards whatever makes the API the least confusing, which appears to be
> > > Johannes' original change, but I'd support a patch which always set it to
> > > 0 instead if it was deemed safer.
> >
> > On the other hand.. As I mentioned earlier, if someone's code is
> > failing because of the permissions change, they can chmod
> > /proc/sys/vm/drop_caches at boot time and be happy. They have no such
> > workaround if their software misbehaves due to a read always returning
> > "0".
>
> I lied. I can chmod things in /proc but I can't chmod things in
> /proc/sys/vm. Huh, why did we do that?
To conserve memory! It was in 2007.
For the record I support 0200 on vm.drop_caches.
commit 77b14db502cb85a031fe8fde6c85d52f3e0acb63
[PATCH] sysctl: reimplement the sysctl proc support
+static int proc_sys_setattr(struct dentry *dentry, struct iattr *attr)
+{
+ struct inode *inode = dentry->d_inode;
+ int error;
+
+ if (attr->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID))
+ return -EPERM;
