Yup, consider that there are some filesystem APIs that allow root to have r/w access to all inodes and their attributes in a filesystem because they bypass the filesystem namespace altogether...
Posted Mar 21, 2013 7:42 UTC (Thu) by lkundrak (guest, #43452)
[Link]
I'm curious, which ones they are?
Complexity
Posted Mar 21, 2013 14:36 UTC (Thu) by dpquigl (subscriber, #52852)
[Link]
I'm actually confused as to what his statement is to begin with. Root by virtue of having privileged access can do whatever it wants to any file assuming you don't bring capabilities or other access controls into the picture. Saying root has access to read/write to any inode or change any attributes is a vacuous statement since root can open any file in the filesystem read/write to begin with by virtue of being root. You don't need special APIs for that you just use open. Maybe he's talking about debug file systems or tools that are available for certain file systems like XFS that let you manipulate the inodes of a filesystem directly?
Complexity
Posted Mar 21, 2013 16:52 UTC (Thu) by butlerm (subscriber, #13312)
[Link]
> Root by virtue of having privileged access can do whatever it wants to any file
Isn't "root" now an ambiguous term? Don't we now have local root and global or system root? We certainly don't want local root to have privileges to do things like open arbitrary files by inode number. For filesystems the local root mounted or owns perhaps, but certainly not with regard to filesystems mounted by system root or other local root users.
Unless the idea is to adopt the convention that "root" always refers to system root, and never to local root without further qualification, any such reference is likely to lead to some considerable degree of confusion. This thread is a perfect example.
Complexity
Posted Mar 21, 2013 21:05 UTC (Thu) by dgc (subscriber, #6611)
[Link]
> Maybe he's talking about debug file systems or tools that are available
> for certain file systems like XFS that let you manipulate the inodes
> of a filesystem directly?
File handles are the problem. And when combined with interfaces like bulkstat, you've got a capability to find, open and *invisibly modify* any file in the filesystem regardless of namespace restrictions...