Re: Feature request: sticky bit inheritance

From: Julian Elischer <julian_at_freebsd.org>
Date: Thu, 28 Nov 2013 08:05:51 +0800
On 11/28/13, 12:17 AM, Harald Schmalzbauer wrote:
>   Bezüglich Julian Elischer's Nachricht vom 27.11.2013 16:20 (localtime):
>> On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote:
>>>    Hello,
>>>
>>> ever since I took a FreeBSD machine into production, acting as any kind
>>> of file server, I have to work arround the problem, that write access to
>>> a directory implies unlinking (deleting) directory contents.
>> not sure I fully understand what you mean by that..
>> Do you mean write access implies delete access? yes..
>>
>> This can be modified with the nounlink flag.
> The uunlink flags also prohibits the owner to delete his files as far as
> I know. I want to prohibt users from deleting “foreign” files, even if
> the user has write access to the parent directory (and I wanted to
> explain that I don't understand why anybody would want that a user with
> write access to a directory can delete files on which the user doesn't
> have write access).

You can always unlink a file that is not yours if you own the directory.
because the ability to unlink is purely dependent on the directory.
You don't change the file, and it may in fact have other links
The 'nounlink' flags change this.
> The sticky bit exactly does what I need (and should be the default
> behaviour in my opinion).
> But my problem is that the stick bit must be added to each single
> directory after creation, it's not inherited.
correct.

> I'd need every child directory of directories, who have the sticky bit
> set, also to have the sticky bit. The same behaviour as with the gid –
> it's the same as the parent has for new directories.
"patches accepted" :-)

I don't think that you are going to have much chance in changing 
default unix behaviour,
but a patch (that can be disabled) would have  a chance if there was a 
really good reason for it.

>
> Thanks,
>
> -Harry
>
Received on Wed Nov 27 2013 - 23:06:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC