From: JT O. <jt...@xn...> - 2012-05-25 16:46:07
|
On Fri, May 25, 2012 at 10:03 AM, Nikolaus Rath <Nik...@ra...> wrote: > On 05/25/2012 11:59 AM, JT Olds wrote: >>> On 05/25/2012 12:12 AM, JT Olds wrote: >>>>>> Another thing to consider is permission checking. Your file system may >>>>> be serving directories for which it (or rather, the UID the fs is >>>>> running under) has no write rights. For these directories, normal >>>>> attempts to create files should fail, but "unmasking" requests should of >>>>> course work. This means that you need to implement your own access() >>>>> method (which you may have done already), but you also need to >>>>> distinguish between ordinary and unmasking requests, e.g. by checking >>>>> the PID of the requesting process. >>>> > [...] >>>> As for access - good point. Luckily for me my use case has the FUSE >>>> process UID owning all of the files and directories its serving. So I >>>> think I'm okay there. >>> >>> Owning them isn't enough. Can you ensure that the user will never do a >>> chmod -w on a directory? >> >> Well, no, the user might do a chmod -w I guess, but as I understand it >> there's really no reason I can't return +w in getattr calls to my PID >> only. > > The kernel would cache it, and it would appear as +w to every process, > not just your PID. Really? How come that stuff is cached? If there's an option to disable the kernel_cache for file data, is there an option to disable metadata caching like that? That just seems bad in general for metadata changing from elsewhere in my network fs. -JT > -- > »Time flies like an arrow, fruit flies like a Banana.« > > PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel |