Re: PATCH - ext2fs privacy (i.e. secure deletion) patch

Bill Davidsen
2004-02-07T03:28:31Z

Valdis.Kletnieks@vt.edu wrote:
> On Wed, 04 Feb 2004 18:47:54 EST, Bill Davidsen said:
>
>>>This of course implies that 'chattr +s' (or whatever it was) has to fail
>>>if the link count isn't exactly one.
>>
>>Do you disagree that the count does need to be one?
>
>
> I'm not prepared to say that there's no scenario where we *dont* care
> how many links there are, as long as the file *does* get wiped when the
> last one goes away.
>
> The MH mail handler stores each message in a file - so a mail message is easily
> stored in multiple folders by simply using multiple hard links. I could
> easily see having mail that I want to +s and go away when I remove it from
> the last folder it was in....

This is then a question of what we want it to do, and I assume that
either of the obvious behaviours is not only possibe but practical. The
question is if the objective is to make the data go away when the last
link is removed, or to make removal of sach a file (unlink) remove the
contents at the time of the unlink. I think the latter clearly implies
allowing a single link to the inode.

Since I could make a case for either, I'd like to hear other feedback.
>
>
>>I agree with everything you said, "useful" doesn't always map to "easy."
>>But if you agree that the count needs to be one on files, then you could
>>also fail if you tried to add it to a directory which was not empty.
>
>
> Yes you could. The question is whether that's a desired semantic or not.

Given my use of the 'setgid' bit as a possible model, I would say that
having new files created with the attribute is useful, and the user
putting the attribute on the directory should control the content at the
time the attribute is set. In other words it will be as useful if we
just make it apply on files as they are created.
>
>
>>In case I didn't make it clear, the use I was considering was to create
>>a single directory in which created files would really go away when
>>deleted. I hadn't considered doing it after files were present, what you
>>say about overhead is clearly an issue. I think I could even envision
>>some bizarre race conditions if the kernel had to do marking of each
>>file, so perhaps it's impractical.
>
>
> As I said, ugly and murky....

And not needed.
>
>
>>But what happens when the 'setgid' bit is put on a directory? At least
>>in 2.4 existing files do NOT get the group set, only files newly
>>created. So unless someone feels that's a bug which needs immediate
>>fixing, I can point to it as a model by which the feature could be
>>practically implemented.
>
>
> Ahh.. but now you're suggesting a different model than "directory must
> be empty". Obviously more discussion of what we *want* it to do is needed ;)

Yes, the person setting the attribute can control this. Unlike the
setgid bit it can't be done (currently) as a part of creat().

--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979