openssh unix dev - Oct 2018 - please remove permission check that disallows private-group access.

I'm new here, but I feel like chiming in, I hope my opinions are 
welcome. At first glance at this thread it seems unnecessary to argue 
about the necessity of these checks when when the option exists to give 
users the choice.

Adding configuration option(s) for users who wish to bypass these checks 
could allow experienced users to do what they need to, and less 
experienced users could still benefit form the protection by default.

Generally, giving users the choice should not be controversial, but I 
will note that there is the mild fear of a user googling the error and 
finding misguided advice to simply disable the check.

Charlie

the determined sysadmin can just copy the keys where they want them to
be and run chmod. problem solved. no need for a new client side config
option, which carries a non-zero cost of ongoing maintenance.

Cheers,
peter

On Mon, Oct 22, 2018 at 2:20 PM Charlie Smurthwaite <charlie at
atech.media> wrote:
>
> I'm new here, but I feel like chiming in, I hope my opinions are
> welcome. At first glance at this thread it seems unnecessary to argue
> about the necessity of these checks when when the option exists to give
> users the choice.
>
> Adding configuration option(s) for users who wish to bypass these checks
> could allow experienced users to do what they need to, and less
> experienced users could still benefit form the protection by default.
>
> Generally, giving users the choice should not be controversial, but I
> will note that there is the mild fear of a user googling the error and
> finding misguided advice to simply disable the check.
>
> Charlie
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 10/22/18, 5:42 PM, "openssh-unix-dev on behalf of Peter Moody"
<openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of mindrot
at hda3.com> wrote:

    the determined sysadmin can just copy the keys where they want them to
    be and run chmod. problem solved. 

Not so fast. If a home directory is on an NFS or AFS filesystem, where would
that "determined sysadmin" copy the keys to? Not to mention the
question of what business that "determined sysadmin" has touching my
keys?

    no need for a new client side config option, which carries a non-zero
    cost of ongoing maintenance.

The cost of ongoing maintenance does not exceed the cost of dealing with this
problem.

    
    On Mon, Oct 22, 2018 at 2:20 PM Charlie Smurthwaite <charlie at
atech.media> wrote:
    >
    > I'm new here, but I feel like chiming in, I hope my opinions are
    > welcome. At first glance at this thread it seems unnecessary to argue
    > about the necessity of these checks when when the option exists to give
    > users the choice.
    >
    > Adding configuration option(s) for users who wish to bypass these
checks
    > could allow experienced users to do what they need to, and less
    > experienced users could still benefit form the protection by default.
    >
    > Generally, giving users the choice should not be controversial, but I
    > will note that there is the mild fear of a user googling the error and
    > finding misguided advice to simply disable the check.
    >
    > Charlie
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev at mindrot.org
    > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev at mindrot.org
    https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20181022/f00e312a/attachment.p7s>

On Mon, 22 Oct 2018, Charlie Smurthwaite wrote:
> Generally, giving users the choice should not be controversial, but I will
> note that there is the mild fear of a user googling the error and finding
> misguided advice to simply disable the check.
That's exactly what I believe will happen if we include an option.
Then we're stuck having to maintain a useless option in perpetuity.