This is the mail archive of the 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: cron in cygwin

> > 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
> > > Perhaps Pierre or Corinna could comment on this?

> > It reproduces 100% of the time.  I've tried it on several different
> > 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,
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
need to do  a setfacl command on to make sure the permissions really are
what they claim to be.


Unsubscribe info:
Problem reports:

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