Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > muc.lists.netbsd.tech.security > #250 > unrolled thread

Re: Hard link creation witout write access

Back to article view | Back to muc.lists.netbsd.tech.security

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Hard link creation witout write access Greg Troxel <gdt@lexort.com> - 2023-09-10 10:04 -0400
    Re: Hard link creation witout write access Greg Troxel <gdt@lexort.com> - 2023-09-10 10:36 -0400

#250 — Re: Hard link creation witout write access

Taylor R Campbell <riastradh@NetBSD.org> writes:

>> The implementation may require that the calling process has
>> permission to access the existing file.
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html
>
> So this behaviour is allowed by POSIX but it would also be allowed to
> make this fail with EACCES.  Unclear whether POSIX means ownership,
> group membership, write access, or read access, but unless a POSIX
> language lawyer can cite chapter & verse for the specific definition
> of `has permission to access', I think this means the implementation
> is allowed to apply any of those access rules?
>
> Apparently we have sysctl knobs
>
> security.models.extensions.hardlink_check_uid
> security.models.extensions.hardlink_check_gid
>
> to prohibit this bonkers linking, by prohibiting anyone but the owner
> (hardlink_check_uid) or members of the group (hardlink_check_gid) from
> creating hard links.  But the knobs are off by default.

How about we add

  security.models.extensions.hardlink_require_access

and define as (uid match || writable), default off for now, and all the
people that want this change and enable it on all their production
systems and if there is no trouble we can just default it to on.  I
would rather do that more slowly than accumulate crud in sysctl.conf.

Or perhaps have people just check_uid and then turn that on by default
and call "owns" as good enough for "access".

I do not expect much to break.  But I am always surprised.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [next] | [standalone]

#251

Greg Troxel <gdt@lexort.com> writes:

>> Apparently we have sysctl knobs
>>
>> security.models.extensions.hardlink_check_uid
>> security.models.extensions.hardlink_check_gid
>>
>> to prohibit this bonkers linking, by prohibiting anyone but the owner
>> (hardlink_check_uid) or members of the group (hardlink_check_gid) from
>> creating hard links.  But the knobs are off by default.

Also, why is "check_gid" rational?  While posix admits all sorts of
stuff, the issue is semi-obviously "am I allowed to do stuff with this
file" and "is my gid the same" seems unlikely to be right.   So perhaps
those should be dropped in favor of hardlink_check_access.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [prev] | [standalone]

Back to top | Article view | muc.lists.netbsd.tech.security

csiph-web