On Thu, Sep 15, 2011 at 01:27:57PM +0400, Vasiliy Kulikov wrote: ... > > > in case two of them has a mapping shared, we map > > the memory by the 1st one and then open its /proc/$pid/map_files/address file and > > map it by the 2nd task. > > How can you restore a set of processes in case they share an RW mapping > as RW in both tasks if you deny opening /proc/$pid/map_files/$address as W? I can read the link first to figure out the file path and re-open it as rw via path itself (which implies the restorer still must have enough rights to open it as rw). > > > Using /proc/$pid/maps for this is quite inconvenient since it brings repeatable > > re-reading and reparsing for this text file which slows down restore procesure > > significantly. Also as being pointed in (3) it is a way easier to use top level > > shared mapping in children as /proc/$pid/map_files/address when needed. > [...] > > v14: (by Vasiliy Kulikov) > > - for security reason the links are created with FMODE_READ mode > > only even if the former file has FMODE_WRITE > > - proc_map_files_lookup fails on any non-read-only queries. > > Do you have a PoC of the dumper? At least without the restorer. If we > see an implementation of map_files/ user we probably identify what > operation it needs and what security restrictions we have to define. Yeah, i'll ping you the link (while beign trying various approaches the code end up in being a pure mess, so until all cleaned up and works as expected i'll not public it). Cyrill -- 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
