On Thu, 20 Mar 2014 16:12:54 +0100 David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > Hi > > On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes > <gnomes@xxxxxxxxxxxxxxxxxxx> wrote: > > I think you want two things at minimum > > > > owner to seal > > root can always override > > Why should root be allowed to override? Because root can already override it by say mmapping the kernel memory and patching. It also tends to be valuable for debugging horrible problems with complex systems. Imposing fake restrictions on root just causes annoyance when doing stuff like debugging but doesn't actually change the security situation. > > I'm fine with F_SET/GET_SEALS. But given you suggested requiring > MFD_ALLOW_SEALS for sealing, I don't see why we couldn't limit this > interface entirely to memfd_create(). But if someone does find a non memfd use for it then it's useful not to have to go "this fnctl for memfd, that fnctl for the other" Just planning ahead. > > Whether you want some way to undo a seal without an exclusive reference as > > the file owner is another question. > > No. You are never allowed to undo a seal but with an exclusive > reference. This interface was created for situations _without_ any > trust relationship. So if the owner is allowed to undo seals, the > interface doesn't make any sense. The only options I see is to not > allow un-sealing at all (which I'm fine with) or tracking users (which > is way too much overhead). Ok - that makes sense -- 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>