Re: immutable files via O_OBJECT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 09, 2014 at 10:10:22AM +0000, Colin Walters wrote:
> 
> And the more I thought about it, the more I realized what would be neat is a
> new open flag "O_OBJECT". What this would do is disallow any further changes
> to content after the file has been close()d or so.

What's the security properties that this would buy you over simply
doing something like this?

       fchmod(fd, 0444);

Sure, root (or the owner) could change the always change the
permissions on the file --- but root can always modify the file by
opening the block device directly using a tool like debugfs.  So if
you need to guarantee that the object hasn't changed, you're going to
have to you a cryptographic checksum, or such as what git does.

I suppose the one benefit is that you could have a file which is owned
by some uid other than root, and still have some form of immutability
guarantees, which might be useful if you need the uid for (a) quota
purposes, (b) setuid/setgid purposes, and (c) so that a non-root user
can create one of these objects.

But in order to do this, we would have to plumb through glibc, VFS,
and low-level file system changes for a non-portable feature that
would only be useful in Linux systems.  Is it really worth it?

      	      	     	      		- Ted
--
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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux