Hi On Mon, Jun 2, 2014 at 12:59 PM, Hugh Dickins <hughd@xxxxxxxxxx> wrote: > On Fri, 23 May 2014, David Herrmann wrote: >> On Tue, May 20, 2014 at 4:20 AM, Hugh Dickins <hughd@xxxxxxxxxx> wrote: >> > But this does highlight how the "size" arg to memfd_create() is >> > perhaps redundant. Why give a size there, when size can be changed >> > afterwards? I expect your answer is that many callers want to choose >> > the size at the beginning, and would prefer to avoid the extra call. >> > I'm not sure if that's a good enough reason for a redundant argument. >> >> At one point in time we might be required to support atomic-sealing. >> So a memfd_create() call takes the initial seals as upper 32bits in >> "flags" and sets them before returning the object. If these seals >> contain SEAL_GROW/SHRINK, we must pass the size during setup (think >> CLOEXEC with fork()). > > That does sound like over-design to me. You stop short of passing > in an optional buffer of the data it's to contain, good. > > I think it would be a clearer interface without the size, but really > that's an issue for the linux-api people you'll be Cc'ing next time. > > You say "think CLOEXEC with fork()": you have thought about this, I > have not, please spell out for me what the atomic size guards against. > Do you want an fd that's not shared across fork? My thinking was: Imagine a seal called SEAL_OPEN that prevents against open() (specifically on /proc/self/fd/). That seal obviously has to be set before creating the object, otherwise there's a race. Therefore, I'd need a "seals" argument for memfd_create(). Now imagine there's a similar seal that has such a race but prevents any following resize. Then I'd have to set the size during initialization, too. However, in my opinion SEAL_OPEN does not protect against any real attack (it only protects you from yourself). Therefore, I never added it. Furthermore, I couldn't think of any similar situation, so I now removed the "size" argument and made "flags" just an "unsigned int". It was just a precaution, but I'm fine with dropping it as we cannot come up with a real possible race. Sorry for the confusion. I'll send v3 in a minute. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
