Re: Feature request: sticky bit inheritance
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 signature.asc Description: OpenPGP digital signature
Re: Feature request: sticky bit inheritance
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature request: sticky bit inheritance
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). 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. 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. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: Feature request: sticky bit inheritance
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. (man 2 chflags) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
