Theodore Ts'o <tytso@xxxxxxx> writes: > On Tue, May 09, 2017 at 02:17:46PM -0700, Eric Biggers wrote: >> 1.) Privacy implications. Say the filesystem is being shared between multiple >> users, and one user unpacks foo.tar.gz into their home directory, which >> they've set to mode 700 to hide from other users. Because of this new >> ioctl, all users will be able to see every (inode number, size in blocks) >> pair that was added to the filesystem, as well as the exact layout of the >> physical block allocations which might hint at how the files were created. >> If there is a known "fingerprint" for the unpacked foo.tar.gz in this >> regard, its presence on the filesystem will be revealed to all users. And >> if any filesystems happen to prefer allocating blocks near the containing >> directory, the directory the files are in would likely be revealed too. > > Unix/Linux has historically not been terribly concerned about trying > to protect this kind of privacy between users. So for example, in > order to do this, you would have to call GETFSMAP continously to track > this sort of thing. Someone who wanted to do this could probably get > this information (and much, much more) by continuously running "ps" to > see what processes are running. > > (I will note. wryly, that in the bad old days, when dozens of users > were sharing a one MIPS Vax/780, it was considered a *good* thing > that social pressure could be applied when it was found that someone > was running a CPU or memory hogger on a time sharing system. The > privacy right of someone running "xtrek" to be able to hide this from > other users on the system was never considered important at all. :-) > > Fortunately, the days of timesharing seem to well behind us. For > those people who think that containers are as secure as VM's (hah, > hah, hah), it might be that best way to handle this is to have a mount > option that requires root access to this functionality. For those > people who really care about this, they can disable access. What would be the reason for not putting this behind capable(CAP_SYS_ADMIN)? What possible legitimate function could this functionality serve to users who don't own your filesystem? I have seen several people speak up how this is a concern I don't see anyone saying here is a legitimate use for a non-system administrator. This doesn't seem like something where abuses of time-sharing systems can be observed. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
