Hi On Thu, Apr 16, 2015 at 10:14 AM, Konstantin Khlebnikov <koct9i@xxxxxxxxx> wrote: > On Thu, Apr 16, 2015 at 10:23 AM, Michael Tirado <mtirado418@xxxxxxxxx> wrote: >> Hi everyone, I have 2 questions (see comments marked with "Question:") >> that I am hoping to get some input on. Any feedback in general you can offer >> is greatly appreciated. Most importantly, I would like to be sure that this >> is a valid way to implement such a seal. This is my first kernel modification >> and I haven't been following the mailing list for very long (for the record >> in case there is a dumb mistake in here) I don't know any kernel devs and >> figured this would be the most appropriate place to find some useful feedback. >> >> This seal is similar to F_SEAL_WRITE, but will allow the task that created the >> memfd to continue writing and retain a single shared writable mapping. Needed for >> one-way communication between processes, authenticated at the task level. >> Currently the only way to accomplish this is by constantly creating, filling, >> sealing write, then sending memfd. Also, a different name suggestion is welcome. > > I guess that was in original design but was dropped for some reason. No. This is not what sealing is about. Seals are a property of an object, they're unrelated to the process accessing it. Sealing is not an access-control method, but describes the state and capabilities of a file. The same functionality of F_SEAL_WRITE_NONCREATOR can be achieved by opening /proc/self/fd/<num> with O_RDONLY. Just pass that read-only FD to your peers but retain the writable one. But note that you must verify your peers do not have the same uid as you do, otherwise they can just gain a writable descriptor by opening /proc/self/fd/<num> themselves. Thanks David -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>