[Bug 3982] New: WARNING: UNPROTECTED PRIVATE KEY FILE does not do what it is expected to do.

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3982

            Bug ID: 3982
           Summary: WARNING: UNPROTECTED PRIVATE KEY FILE does not do what
                    it is expected to do.
           Product: Portable OpenSSH
           Version: 10.4p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: for_bugzilla.mindrot.org_2022-09-08 at lockywolf.net

The file authfile.c has the following code (commit
7e446d3f5917c2f2770981a89d0e54d5d064bf0c) Date:   Wed Jul 22 00:37:24
2026 +0000

        /*
         * if a key owned by the user is accessed, then we check the
         * permissions of the file. if the key owned by a different
user,
         * then we don't care.
         */
#ifdef HAVE_CYGWIN
        if (check_ntsec(filename))
#endif
        if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
               
error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
                error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!
         @");
               
error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
                error("Permissions 0%3.3o for '%s' are too open.",
                    (u_int)st.st_mode & 0777, filename);
                error("It is required that your private key files are
NOT accessible by others.");
                error("This private key will be ignored.");
                return SSH_ERR_KEY_BAD_PERMISSIONS;
        }

It seems logical: if you own the file, you are expected to make it
private and not give other users; if you do not own the file, you
cannot change its properties, so you can go on.

Seems clear, logical, straightforward, and in line with the comment.

However, this is not what is actually happening.

In fact, the opposite policy is implemented. If you are the owner, no
message is displayed and you can log in, despite the permissive
permissions. If you are a _different_ user, a message is displayed.
It's trivial to work around the issue by copying file into a file you
own, so the warning is moot.

It's also clear where the issue is coming from. 
You are writing 
(st.st_uid == getuid()) && (st.st_mode & 077) != 0

What should be written, however, is 

((st.st_uid == getuid()) && (st.st_mode & 077)) != 0)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.