ntsec and remote copy
Hi, I have a problem with ntsec I think. I copied files from a remote disk (a Windows NT server) using the explorer. These files are then set to the following UID: ls -l test.txt -rwx--1 65535None 1225 Dec 10 11:30 test.txt If I create a file locally myself, I nicely get -rw-rw-rw-1 kris None 1230 Dec 10 13:46 local.txt and the same nice UID when I use bash and cp to copy the remote file. It's also fine when I do an 'ls -l' of the remote file by the way. So, where does cygwin get that funny UID (and permissions) from? cygcheck.out attached. Thanks Kris Thielemans (kris.thielemans ic.ac.uk) Imaging Research Solutions Ltd Cyclotron Building Hammersmith Hospital Du Cane Road London W12 ONN, United Kingdom web site address: http://www.irsl.org/~kris cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: ntsec and remote copy
Oh yes, a related remark. On the file with the funny UID, some things work, some don't. For instance, I can vi it, but I cannot write it. This seems to say that some cygwin programs call this file readable, but others don't... Bearing in mind the premissions that it is said to, I would actually claim that I should NOT be able to read it. Here's an illustration of 'test' that cannot read it. $ ls -l test.txt -rwx--+ 1 65535None 1003 Dec 10 00:24 test.txt $ if [ -r test.txt ]; then echo 'I can read it'; else echo 'I cannot read it'; fi I cannot read it $ chown kris test.txt $ ls -l test.txt -rwx--1 kris None 1003 Dec 10 00:24 test.txt $ if [ -r test.txt ]; then echo 'I can read it'; else echo 'I cannot read it'; fi I can read it I also see now that not only files copied remotely have this strang eUID, but others as well (maybe older files?) Kris > -Original Message- > From: Kris Thielemans [mailto:[EMAIL PROTECTED]] > Sent: 10 December 2002 14:03 > To: Gnuwin > Cc: Kris Thielemans > Subject: ntsec and remote copy > > > Hi, > > I have a problem with ntsec I think. > I copied files from a remote disk (a Windows NT server) using the > explorer. > These files are then set to the following UID: > > ls -l test.txt > -rwx--1 65535None 1225 Dec 10 11:30 test.txt > > If I create a file locally myself, I nicely get > -rw-rw-rw-1 kris None 1230 Dec 10 13:46 local.txt > > and the same nice UID when I use bash and cp to copy the remote file. It's > also fine when I do an 'ls -l' of the remote file by the way. > > So, where does cygwin get that funny UID (and permissions) from? > > cygcheck.out attached. > > Thanks > > Kris Thielemans > (kris.thielemans ic.ac.uk) > Imaging Research Solutions Ltd > Cyclotron Building > Hammersmith Hospital > Du Cane Road > London W12 ONN, United Kingdom > > web site address: http://www.irsl.org/~kris > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ntsec and remote copy
On Tue, Dec 10, 2002 at 02:02:59PM -, Kris Thielemans wrote: > I have a problem with ntsec I think. > I copied files from a remote disk (a Windows NT server) using the explorer. > These files are then set to the following UID: > > ls -l test.txt > -rwx--1 65535None 1225 Dec 10 11:30 test.txt > > If I create a file locally myself, I nicely get > -rw-rw-rw-1 kris None 1230 Dec 10 13:46 local.txt Kris, The owner of the remote file has a SID that does not appear in your passwd file and thus it cannot be mapped to a uid. Cygwin then uses uid = -1 This also explains what you describe in your follow up message. Perhaps the Windows security gui or the cacls program will reveal the identity of the owner. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: ntsec and remote copy
Hi Pierre, thanks for your reply! That indeed turned out to be the case. > The owner of the remote file has a SID that does not appear > in your passwd file and thus it cannot be mapped to a uid. > Cygwin then uses uid = -1 > This also explains what you describe in your follow up > message. > > Perhaps the Windows security gui or the cacls program will > reveal the identity of the owner. > > Pierre What happened was the following: - I had trimmed down my /etc/passwd file (I think I read somewhere it was advisable to remove users from there for which you don't want access. For example when running telnetd, this seems to be the only way to restrict access). In the process, I also removed the Administrators group from /etc/passwd. (I don't really want somebody to break into my system as Administrator via telnet) - I am member of the Administrators group, so as the ntsec doc mentions, all files I create are owned by Administrators, but that wasn't in /etc/passwd, so it's an unrecognised user. Adding Administrators to /etc/passwd solved my problems. Remaining questions: - is there another way to prevent specific users access to telnet or ftp ? (or ssh when I get round to installing sshd) ? - It seems cygwin does not use the above mentioned behaviour that files that I create are owned by Administrators, instead they are owned by myself. This is fine for me, but I guess worth mentioning in the doc. - I still don't understand why certain cygwin programs could read the file and others not (see mail below). It can't be NT, because I could obviously read/write all files I created myself using NT programs. So, I have the impression that some cygwin programs use ntsec in different ways. For example, cat or vi could read the file with an unrecognised owner, but test -r couldn't. (I recently reinstalled and upgraded the whole of cygwin, so I don't think it's because I have old versions lying around). Thanks for the help Kris > -Original Message- > From: Kris Thielemans [mailto:[EMAIL PROTECTED]] > Sent: 10 December 2002 16:26 > To: Gnuwin > Subject: RE: ntsec and remote copy > > > Oh yes, > a related remark. > > On the file with the funny UID, some things work, some don't. For > instance, I can vi it, but I cannot write it. This seems to say > that some cygwin programs call this file readable, but others > don't... Bearing in mind the premissions that it is said to, I > would actually claim that I should NOT be able to read it. > > Here's an illustration of 'test' that cannot read it. > > $ ls -l test.txt > -rwx--+ 1 65535None 1003 Dec 10 00:24 test.txt > > $ if [ -r test.txt ]; then echo 'I can read it'; else echo 'I > cannot read it'; > fi > I cannot read it > > $ chown kris test.txt > > $ ls -l test.txt > -rwx--1 kris None 1003 Dec 10 00:24 test.txt > > $ if [ -r test.txt ]; then echo 'I can read it'; else echo 'I > cannot read it'; > fi > I can read it > > > I also see now that not only files copied remotely have this > strang eUID, but others as well (maybe older files?) > > Kris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ntsec and remote copy
On Thu, Dec 12, 2002 at 12:00:51PM -, Kris Thielemans wrote: > Remaining questions: > - is there another way to prevent specific users access to telnet or ftp ? > (or ssh when I get round to installing sshd) ? Edit /etc/passwd and set the shell field to /something/invalid/but/not/empty > - I still don't understand why certain cygwin programs could read the file > and others not (see mail below). It can't be NT, because I could obviously > read/write all files I created myself using NT programs. So, I have the > impression that some cygwin programs use ntsec in different ways. For > example, cat or vi could read the file with an unrecognised owner, but > test -r couldn't. (I recently reinstalled and upgraded the whole of cygwin, > so I don't think it's because I have old versions lying around). test -r does not read the file. It relies on permission bits to predict if you can read the file. Unfortunately Windows works with acls. It is not possible to perfectly map all acls into permission bits. In this case the prediction was incorrect. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
