X-Spam-Check-By: sourceware.org Date: Wed, 18 Oct 2006 11:18:15 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Shared home dir, samba workgroups and ssh Message-ID: <20061018091815.GD8323@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Oct 17 23:50, Andrew DeFaria wrote: > Andrew DeFaria wrote: > >But when dealing with Samba servers who are configured into workgroups > >innocuous activities in Cygwin would elicit permission denied > >messages. For example, touching a file in the home directory and > >indeed even vi'ing a file, etc. Creating a file within Windows > >Explorer or using other Windows oriented tools would work just fine. > >Files created on the Unix/Linux side would also work fine but when > >looked at from Cygwin on the PC would have odd (read "nobody") > >ownerships and permissions. To make a long story short, the problem are permissions. The typical Windows tool doesn't give a [censored] for the content of the ACL of the file it's working on. The typical Windows tool assumes that permissions will be just right. If it can open/write/close a file, fine. If not, it complains. That's not the case for the typical Cygwin tool. When creating files, the permissions are set to POSIX compatible settings (assuming "ntsec" is set). Some POSIX tools test permissions before trying to manipulate files, etc. Here's the problem with Samba in Workgroups. There's no mapping between the Windows user account and the Samba user account. The files and directories are not yours, the user account on the Windows client, but the files are yours, your user account on the Samba machine. Taking Cygwin out of the picture, have a look using cacls and see how it prints the ACL of a file on the Samba share. Now guess what applications which care for POSIX permissions have to say about this. Then there's the additional problem with permission bits mapped to DOS file attributes, see `man smb.conf', search for "map hidden", "map read only", "map system". > >So I thought the simple solution was to remove SMBNTSEC from my Cygwin > >environment and all would be fine. And indeed it is! Well almost... > > > >Along comes ssh... > > [...] > >What I believe is > >happening is that because my home directory is SMB mounted and > >SMBNTSEC is off then Cygwin reports that files like ~/.ssh/id_rsa are > >0644 even if I change them on Unix/Linux to 0600. Correct. Additionally, ssh(d) doesn't take "smbntsec" into account when trying to figure out if the file permissions are important or not. It just checks for "ntsec" and, FWIW, "ntea". > >Is there any way to work around this problem (short of reconfiguring > >the Samba server)? > Anybody care to venture a guess here? Is my suspicions about SMBNTSEC > correct? As Larry proposed, "StrictModes no" or mapping .ssh to a local directory should help. Another choice would be to start sshd with "nontsec". Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/