From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11480 invoked by alias); 4 Nov 2017 15:30:12 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 11445 invoked by uid 89); 4 Nov 2017 15:30:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,FREEMAIL_REPLYTO,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=openssh, re-ran, github, ls X-HELO: mail-pg0-f50.google.com Received: from mail-pg0-f50.google.com (HELO mail-pg0-f50.google.com) (74.125.83.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 04 Nov 2017 15:30:08 +0000 Received: by mail-pg0-f50.google.com with SMTP id r25so4884799pgn.4 for ; Sat, 04 Nov 2017 08:30:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:reply-to:references:to:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=JLL/d0rjUZc8RqHsOU8RPUq+EQIHcR3uNdboBqyQqFg=; b=h8coLsWpELTq98nUnttBcVyiUlEiP27PJUmsgSjJsPbOFZKKZOtdhWpPSTamb4bdin UHnxYirJF63iyNz7DCqbn/haf+09zMGRKzw6n3o+4g6fkdGOSWXjOSaipUSIQTjMlQ7i rfeAai67pcIH14f56p8BQ+TBoX0HkkrC+7TpTyeL7xMQnEzOz0nqg9cr8Tu5ecnQa+h8 kSPoJeRgVPCv8UgRdEkUkYTd9qOHpco/MHRyOCagft4LZ7r71HItqtP9mwJlE3Ra+YKt 5sW7EMkENcVq4JUpVXorSE9JbsOtk4kOX6ybxZMid7yQZ+Isx+zpPCI6k3eRKKFxy9Xe 6dZA== X-Gm-Message-State: AJaThX7k6NDZ/UhSM9HgpPKq9peiYgnUx+rD95/9kNtgyPBZnvuKQjfp I4+fIi8ZBq7NVE9Li2QWHOxnb8os X-Google-Smtp-Source: ABhQp+R4Jf7F0Ltt6Z6gqVfETeqmQotwtEfphchUvBtEpRfJ6wO1aNVYku9sdi5EKKmyg5a97kDZWQ== X-Received: by 10.84.168.99 with SMTP id e90mr3590588plb.195.1509809403457; Sat, 04 Nov 2017 08:30:03 -0700 (PDT) Received: from [10.0.1.111] (ip68-230-148-254.ri.ri.cox.net. [68.230.148.254]) by smtp.gmail.com with ESMTPSA id d76sm17701663pfk.69.2017.11.04.08.30.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Nov 2017 08:30:02 -0700 (PDT) From: "Matt D." X-Google-Original-From: "Matt D." Subject: Re: No way to use ssh ~/.ssh/config with "noacl" option Reply-To: codespunk+cygwin@gmail.com References: <59FD8C99.8010703@gmail.com> <20171104113723.GC18070@calimero.vinschen.de> <59FDA8D9.6050808@gmail.com> <59FDC12F.1080005@codespunk.com> To: cygwin@cygwin.com Message-ID: <59FDDCFA.9030306@codespunk.com> Date: Sat, 04 Nov 2017 15:30:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <59FDC12F.1080005@codespunk.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00082.txt.bz2 On 11/4/2017 9:31 AM, Matt D. wrote: > On 11/4/2017 7:47 AM, Matt D. wrote: >> On 11/4/2017 7:37 AM, Corinna Vinschen wrote: >>> On Nov 4 05:47, Matt D. wrote: >>>> I mount with "noacl" as I don't need ACLs for my purposes and prefer to >>>> leave everything up to Windows permissions. >>>> >>>> The problem with this is that ssh insists that ~/.ssh/config be less >>>> permissive. But this file is bound to --rw-r--r-- for this option. >>>> >>>> Would it be appropriate to request ssh to ignore this requirement when >>>> "noacl" present on the mounted volume? >>> >>> Yes, in theory. However, this shouldn't be necessary. >>> >>> Ssh already has code to check extrem perms only in "acl" mounted >>> directories, but it does not have this extra check for config files, >>> basically because it was never necessary: >>> >>> If you use noacl, your file perms are faked to always be 644, or >>> 444 if the DOS R/O bit is set, or 755/555 if executable/directory. >>> Additionally all files are faked as if they are owned by your own >>> account. >>> >>> Ssh checks the config file like this: >>> >>> if (((sb.st_uid != 0 && sb.st_uid != getuid()) || >>> (sb.st_mode & 022) != 0)) >>> fatal("Bad owner or permissions on %s", filename); >>> >>> Which means, 0644 permissions are perfectly fine. As are 755 perms >>> for the ~/.ssh and ~ dirs. >>> >>> I just mounted my home dir "noacl". The perms are as expected: >>> >>> $ ls -ld . .ssh .ssh/config .ssh/id_local >>> drwxr-xr-x 1 corinna vinschen 0 Nov 4 12:27 . >>> drwxr-xr-x 1 corinna vinschen 0 Mar 14 2017 .ssh >>> -rw-r--r-- 1 corinna vinschen 703 Jan 19 2017 .ssh/config >>> -rw-r--r-- 1 corinna vinschen 7329 Jan 12 2017 .ssh/id_local >>> >>> Note especially the too open perms in case of the private keyfile >>> "id_local". Still, I can ssh into one of my other machines just fine. >>> >>> How come this doesn't work for you? >>> >>> >>> Corinna >>> >> >> I don't know why it doesn't work for me other than the reported error. I >> am trying to use ssh combined with git. My .ssh permissions are: >> >> $ls -ld . .ssh .ssh/config .ssh/github >> drwxr-xr-x 1 Matthew D'Onofrio None 0 Nov 4 06:42 . >> drwxr-xr-x 1 Matthew D'Onofrio None 0 Nov 4 04:51 .ssh >> -rw-r--r-- 1 Matthew D'Onofrio None 80 Nov 4 04:51 .ssh/config >> -rw-r--r-- 1 Matthew D'Onofrio None 3243 Nov 3 10:53 .ssh/github >> >> I removed the noacl option in fstab, re-ran Cygwin setup, set >> .ssh/config to 600 and ssh was happy. I then reverted back to noacl and >> the problem returned. >> >> I'm in the process of trying to build openssh with cygpath for debugging >> but this is my first time building anything from Cygwin or using >> cygports so it's taking some time. >> >> >> Matt D. > > Please stand by. Looking into this further. > > > Matt D. The code "sb.st_mode & 022" will always be true unless the group and other bits are set to 0. So 755, 644, 555, or whatever would not work. I made a test build which output the value of sb.st_mode and it displayed as "100770". This value reflected the actual NTFS ACLs and not what was displayed at the bash prompt or by "stat -c %a" (which says 644). This makes sense because Cygwin is pulling the NTFS permissions as there are no Cygwin ACLs defined. The only workaround is to use Window's Security diaglog to disable inherited permissions and remove the Users group. This does seem to satisfy things. I suppose the argument now is whether this behavior should change in the face of a drive mounted with "noacl". It took a bit of guesswork as neither chmod or setfacl was changing the NTFS permissions. Interestingly, a config file that I chmodded when the drive was mounted with Cygwin ACLs still works with ssh even though "noacl" is now defined and it is still part of the HOSTNAME\Users group. Neither stat or getfacl show these permissions but they can be seen in the security tab of the file properties. I'm guessing that it works because it has HOSTNAME\None below HOSTNAME\ or something? Matt D. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple