Date: Thu, 28 Nov 2013 09:27:07 +0100 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Feature request: sticky bit inheritance Message-ID: <5296FE5B.6050208@omnilan.de> In-Reply-To: <529688DF.2010600@freebsd.org> References: <5295DFAD.5070402@omnilan.de> <52960DB5.3090209@freebsd.org> <52961B25.3020109@omnilan.de> <529688DF.2010600@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Bezüglich Julian Elischer's Nachricht vom 28.11.2013 01:05 (localtime): > 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 I have an idea why this kind of permission ist default: It's more expensive to extra check the file permission copmpared to only check the directory permission, the only part which will be altered any way. I guess having the sticky bit set by default would cause extra I/O+check, which might have been too expensive in the past… So the default was to do as less work as needed?!? ... >> 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" :-) Besides horrible C skills, I have no idea where and how to start :-( I hoped somebody else with deeper knowledge is also suffering badly and someone could at least estimate the effort (in hours) needed to implement a inhert-stickybit kernconf option, or even better, a sysctl. Maybe I can pay for it. Thanks, -Harry [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlKW/mAACgkQLDqVQ9VXb8hzKwCeLmlUvMcvXzRsqBtWlcxqEH4g /bIAoJEnSE6HObbV4d341S/0iQvPp8l5 =QHPy -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5296FE5B.6050208>