Hi, > When you uninstall an application you expect all information to be deleted. > If you have n smulylinks where N is greater than 1 you cannot make such > guarantee
Well, I'm not sure I would count "marking the storage as free" as "deleting all information", so it seems somewhat pointless in any case, but I guess that truncating the inode before unlinking it should have the same effect? > On Sep 11, 2015 6:20 PM, "Florian Zumbiehl" <[email protected]> wrote: > > > Hi, > > > > > The rationale is given with the neverallow rule in > > > external/sepolicy/untrusted_app.te: > > > > > > # Do not allow untrusted_app to hard link to any files. > > > # In particular, if untrusted_app links to other app data > > > # files, installd will not be able to guarantee the deletion > > > # of the linked to file. > > > > What's the point of this? And can you at all? > > > > I mean, if it's just about reclaiming user IDs, I guess you might as well > > donate the files to a nobody user before unlinking (and adjust the > > permissions accordingly, etc.). If it's about reclaiming the storage: Why > > would you? Especially so given that there might still be open file > > descriptors that would prevent the storage from being reclaimed anyway. > > > > > # Hard links also contribute to security > > > # bugs, so we want to ensure untrusted_app never has this > > > # capability. > > > neverallow untrusted_app file_type:file link; > > > > Yeah, let's forbid adding 42, too, then! Brilliant! > > > > > A possible middle ground would be to allow apps to create hard links to > > > app data files (i.e. add "allow untrusted_app app_data_file:file link;", > > > amend the neverallow to "neverallow untrusted_app { file_type > > > -app_data_file }:file link;"), while still preventing them from creating > > > hard links to any other files under /data. > > > > I can't really judge whether that's a good idea or not, but if an > > application could create hardlinks between files in its own data directory > > hierarchy, that certainly would sound a lot saner than the current > > situation. > > > > > That would still permit an app to create hard links to another app's > > > data files however. That could be further restricted by setting > > > /proc/sys/fs/protected_hardlinks to 1 (via init.rc), which should > > > prevent creating such hard links unless the app owns the file or has > > > both read and write to it (also prevents linking to suid/sgid and > > > special files, but those are unlikely in app sandboxes). > > > > That sounds reasonable to me. > > > > BTW, has anyone investigated how this prohibition on link() interacts with > > open(O_TMPFILE)/linkat(AT_EMPTY_PATH)? > > > > Regards, Florian > > _______________________________________________ > > Seandroid-list mailing list > > [email protected] > > To unsubscribe, send email to [email protected]. > > To get help, send an email containing "help" to > > [email protected]. > > Interesting! Regards, Florian _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
