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: <006001c31524$9987ddd0$6400a8c0@FoxtrotTech0001> From: "Bill C. Riemers" To: Subject: Re: cron in cygwin Date: Thu, 8 May 2003 01:42:19 -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.1165 > > cygrunsrv: unknown option -- D > > Bill, did you use the *exact* line from /usr/doc/Cygwin/cron.README? No. Looks like you are right. "cron" does have a -D option, even though the cron man page doesn't mention one. > > > Regarding your "NOTE 1" below -- is it reproducible? Could you please > > > post the output of "getfacl filename" before and after "chown filename"? > > > Perhaps Pierre or Corinna could comment on this? > > It reproduces 100% of the time. I've tried it on several different machines > > as well.. ... > Looks fine to me. What error do you get if you try "echo 'hi' >> foo.txt" > after that? What if you try it from a SYSTEM-owned shell? > Igor Yesterday, "EPERM". Today nothing. It no-longer reproduces. I've actually spent several hours trying to figure out why previously the problem occurred on multiple machines, with 100% reproducibility, and even cause many of my attempted daemon installs to fail until I found workarounds. It turns out the problem is I used an old Unix trick to "su". Under XP Home edition, the "SYSTEM" account does not have a password assigned, and the "passwd" command fails to assign a password to it. Consequently "login" does not work for logging in as SYSTEM. The "su" command also fails due to the way setuid is implemented under XP. However, the old hackers trick to "su" is if you have write access to the /etc/passwd file, just change the UID of an account you can login to, and make sure that account is listed after the real account. So, I changed "docbill" to UID 18. Walla, when I start a new console, I am SYSTEM. Then I just edit the UID back to normal, for my next login. However, after I used that trick a few times I realized under CYGWIN the trick doesn't really work. Even though the "id" command will identify me as SYSTEM, and all the files I create will be listed as owned by SYSTEM. When a cygrunsrv daemon tries to read one of those files it gets an EPERM command. The same thing happens when I use that trick to switch between user accounts. So I exited the consoles with the modified UID and stopped using that trick. (Instead I set up a home directory and .ssh/authorized files for use with 'ssh' to do the equivalent of an su.) Several days later, I notice "chown" doesn't work correctly. And the problem exists on multiple machines. Guess what? It appears the effects of the bogus UID trick continue to have effects on the chown command and other file permission commands until the next reboot. Last night we had a bad storm, so I shut all the computers down. Today there is no more chown problem... Just a bunch of files with questionalable permissions that I need to do a setfacl command on to make sure the permissions really are what they claim to be. Bill -- 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/