Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Message-ID: <001e01c3458a$cd0fe440$6902a8c0@markonius> From: "Mark Priest" To: References: Subject: Re: OpenSSH + Public Key Auth + ntsec Date: Tue, 8 Jul 2003 15:54:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 John, I am using Cygwin and sshd with public key authentication on a Windows XP Professional machine and I am seeing the same ACL behavior that you are. I have set the CYGWIN environment variable to "ntsec nontea" "nontsec ntea" and "nontsec nontea". These settings do not affect the fundamental behavior when I copy files using scp (I am using the putty clients from a W2k machine) and when I create directories using ssh with a mkdir command. When files and directories are created the ACLs are set so that there are 3 ACLs of the Allow type. One is for the file owner (which is always the user using the scp or ssh), one is for the prmiary group of the user, and one is for Everybody. There are no allow ACLs for the Administrators group or for SYSTEM. However, on all of my "normal" Windows files and directories not created by Cygwin the Administrators group and SYSTEM do have allow ACLs which must be the default Windows behavior. I am not sure what to suggest to get around this since Cygwin is setting Unix-style permissions on files and directories as constrained by umask and the default directory ACLs set using setfacl. One thing that you could consider doing is writing a client side script that first performs the scp and then executes a remote command on the copied file to change the ACLs using the new setfacl command (or try setting default ACLs on the target directory using setfacl). I used setfacl on a file I copied using scp as follows: cvsuser AT markonius ~/test $ getfacl bogus.c # file: bogus.c # owner: cvsuser # group: cvs user::rw- group::rw- mask:rwx other:rw- cvsuser AT markonius ~/test $ setfacl -m g:Administrators:7,u:SYSTEM:7 bogus.c cvsuser AT markonius ~/test $ getfacl bogus.c # file: bogus.c # owner: cvsuser # group: cvs user::rw- group::rw- group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:rw- When I looked at these files in Windows the Administrators group and the SYSTEM user did have Widnows ACLs that granted most permissions, but not the Full Control that is granted in Windows by default. This might be enough for you, however. One additional observation I have is that I have no trouble changing ownership of a file to a member of the Administrators group even without using setfacl. Even though ACL permissions are not shown for the Administrators group I am able to change file ownership from Windows Explorer if I am logged in as a member of Administrators. Good luck, Mark ----- Original Message ----- From: "John" To: "andrew brian clegg" Cc: Sent: Tuesday, July 08, 2003 2:39 PM Subject: Re: OpenSSH + Public Key Auth + ntsec > Here is the corruption as explained by my NT admin: > > --- Begin --- > Our current ACL is: > > (Owner) : Administrators > Administrators : Full Control > SYSTEM : Full Control > ServiceAccount : Full Control > > Currently, whatever ssh/scp touches - the following ACL gets applied: > > (Owner) : ServiceAccount > Administrators : none (no permissions set) > SYSTEM : none (no permissions set) > ServiceAccount : none (no permissions set) > CREATOR GROUP : none (no permissions set) > CREATOR OWNER : none (no permissions set) > Everyone : Read/Write/Execute > None : none (no permissions set) > --- End --- > > Also, when trying to take ownership of the files in windows (as > administrator), we get the following error: "The security descriptor > structure is invalid". The fix for this was to run xcacls.exe and that > allowed us to take ownership of files and directories. > > Obviously, we're using ssh/scp for moving files around for an automated > process. When files have been pushed to an ssh server, sometimes they are > not accessable by the user that scp'd them in the first place and our jobs > cannot continue. When I first noticed this, I logged in via ssh and saw > these files were owned by the creator but had 0000 perms. I did a "chmod > 0644" and our automated process was then able to continue. This happens > sporadically on some of our machines running cygwin. A work around for > this is to "chmod 0644 " for every file before we do any further > processing of the file (move, copy, open, etc). > > So there are two issues, not sure if they are directly related. One, the > ACL's are getting changed to a point where an administrator can't regain > ownership through normal methods. And two, when files are written, > sometimes they get 0000 perms. > > We have reformatted these machines and done fresh installs and yet the > corruption happens all over again on every machine using cygwin & ssh. > > If there were a way to not use ntsec and use inherited permissions via > nontsec, that would be stellar. > > Thanks again, > John > > On Tue, 8 Jul 2003, andrew brian clegg wrote: > > > > > > > > > On Tue, 8 Jul 2003, John wrote: > > > > > CYGWIN="binmode ntsec tty". > > > > > > When making directories via ssh: > > > ssh "mkdir /cygdrive/d/temp/test" > > > or when copying files via scp: > > > scp file.txt :/cygdrive/d/temp/test > > > > > > the files are given the "ntsec" permissions from cygwin and are corrupting > > > the NTFS filesystem. > > > > Corrupting in what sense? > > > > I use ssh with ntsec set on and haven't seen any corruption yet, I should > > certainly like to know about it if it's likely to happen. Admittedly my > > setup is with password rather than PK authentication though. > > > > Andrew. > > > > > > > > -- > > 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/ > > > > > > > -- > 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/ > > -- 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/