This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: OpenSSH + Public Key Auth + ntsec


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@markonius ~/test
$ getfacl bogus.c
# file: bogus.c
# owner: cvsuser
# group: cvs
user::rw-
group::rw-
mask:rwx
other:rw-

cvsuser@markonius ~/test
$ setfacl -m g:Administrators:7,u:SYSTEM:7 bogus.c

cvsuser@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" <cras@werd.net>
To: "andrew brian clegg" <a.clegg@mail.cryst.bbk.ac.uk>
Cc: <cygwin@cygwin.com>
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 <filename>" 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 <server> "mkdir /cygdrive/d/temp/test"
> > > or when copying files via scp:
> > > scp file.txt <server>:/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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]