A FALLOC_FL_NO_HIDE_STALE followup [LWN.net]

A FALLOC_FL_NO_HIDE_STALE followup

Posted Dec 6, 2012 13:06 UTC (Thu) by andresfreund (subscriber, #69562)
In reply to: A FALLOC_FL_NO_HIDE_STALE followup by bergwolf
Parent article: A FALLOC_FL_NO_HIDE_STALE followup

Well, as the previous article noted, they propose that a mount option restricts usage of that facility to a specific group. So its not like it gives away anything by default.

Afaics the only thing that happened for 3.7 was the introduction of that flag, nothing uses it yet, so there cannot be said too much about the security implications of the real thing...

(Log in to post comments)

A FALLOC_FL_NO_HIDE_STALE followup

Posted Dec 6, 2012 20:45 UTC (Thu) by cesarb (subscriber, #6266) [Link]

I can see one security implication: inexperienced programmers who hear about the flag and use it because "it makes things go faster", and get away with it because the flag does nothing. Then their program is deployed somewhere which actually uses the flag, and their code breaks because it assumed zero-fill.

It would be better if any attempt to use the flag always returned -EPERM.

A FALLOC_FL_NO_HIDE_STALE followup

Posted Dec 6, 2012 20:57 UTC (Thu) by andresfreund (subscriber, #69562) [Link]

There's no user of the flag in the kernel yet, but the proposed patch did exactly that:

int do_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
{
@@ -249,6 +254,11 @@ int do_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
if (ret)
return ret;

+ /* Check for enabling _NO_HIDE_STALE flag */
+ if (mode & FALLOC_FL_NO_HIDE_STALE &&
+ !sysctl_enable_falloc_no_hide_stale)
+ return -EPERM;
+

So such inexperienced programmers would fall on their noses.

I don't think the process in which this got through was great, but why assume the people working on this are stupid?

A FALLOC_FL_NO_HIDE_STALE followup

Posted Dec 6, 2012 21:43 UTC (Thu) by cesarb (subscriber, #6266) [Link]

I just took a look at the current kernel, and the problem I imagined does not exist. The kernel already returns an error if FALLOC_FL_NO_HIDE_STALE is passed to sys_fallocate:

/* Return error if mode is not supported */
if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
return -EOPNOTSUPP;

So any inexperienced programmer incorrectly attempting to use the flag to "make things go faster" will already receive an error, and the fallocate call will do nothing.