Re: [Security] time_attrs argument for security_path_truncate

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

 




On Wed, 2 Jun 2010, Nick Piggin wrote:
>
> It appears like the time_attrs parameter of security_path_truncate is
> unused by any security module, so I wonder if we can remove it?

I think we should aggressively remove interfaces that aren't used. The VFS 
side has been complicated several times because of the security hooks, and 
if they ended up not getting used and just complicates logic, we should 
remove it.

> We cannot really get it right for truncate(2) calls anyway without
> holding i_mutex over the call (because ATTR_MTIME|ATTR_CTIME is
> effectively set iff size changes). So the meaning of this parameter
> today is misleading anyway.

Why do we pass it in to do_truncate() at all, btw? Especially as we seem 
to be a bit confused about it. A regular 'truncate()' passes in a 
time_attrs of '0', while a 'ftruncate()' passes ATTR_MTIME|ATTR_CTIME.

That doesn't sound right. And if it is (because I can well imagine some 
strange and subtle POSIX rule wrt ftruncate() and mtime/ctime), I think we 
should add a comment on it, since I've clearly forgotten the reason.

Btw, right now we pass in ATTR_OPEN too to the security_path_truncate() 
call. Which again doesn't seem to be _used_ by any security thing, and 
which also violates the naming of that argument. So there's some 
additional strangeness going on there.

(That ATTR_OPEN case was introduced in commit be6d3e56a6 ("introduce new 
LSM hooks where vfsmount is available"), for what its worth. The ATTR_OPEN 
bit seems to have been copied from the do_truncate() call below it, I 
think it's just a copy-paste error).

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