Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler <holler@ahsoftware.de>]

Am 03.02.2015 um 07:05 schrieb Al Viro:
> On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote:
>> +	if (inode) {
>> +		// TODO:
>> +		// if (inode is file and 's' flag is set)
>> +		// 	secure = true;
>> +		if (!secure)
>> +			iput(inode);	/* truncate the inode here */
>> +		else {
>> +			struct super_block *sb = inode->i_sb;
>> +			if (sb->s_op->set_secure_delete)
>> +				sb->s_op->set_secure_delete(sb, true);
>> +			// TODO: We should fail if secure isn't supported,
>> +			// look up how that's possible here.
>> +			iput(inode);	/* truncate the inode here */
>> +			// TODO: check if sb is still valid after the inode is gone
>> +			sync_filesystem(sb);
>> +			if (sb->s_op->set_secure_delete)
>> +				sb->s_op->set_secure_delete(sb, false);
>> +		}
>
> Charming.  Now, what exactly happens if two such syscalls overlap in time?
> Moroever, what makes you equate unlink() with inode removal?  What happens
> if you race e.g. with stat(2) on the same thing?  Or if there's an opened
> file over that sucker, for that matter?

Sorry, but I first had to make breakfast after I've got angry about the 
usual arrogance of most Linux kernel maintainers.

I've already answered the first question.

Now to the second. That still might be a problem. But that's why this is 
a RFC, why there is a WIP (Work In Progress) before the patch, why I've 
written I've never looked at those sources before, why I've written they 
are imperfect and why I've written I have not spend much time on these 
patches. I've posted them to show how I think the problem might be 
solved. These patches evolved out of desperation that otherwise users 
have to wait another 30 years until they will be offered a way to really 
delete files.

If the removal is somehow scheduled then, of course, the secure flag has 
to be scheduled too.

Alexander Holler