chmod suddenly ceased to work on old files - NEW FINDINGS
Mon Aug 1 12:22:00 GMT 2005
On Jul 14 12:43, Pierre A. Humblet wrote:
> Corinna (and everybody),
> I looked into the problem reported in the thread.
> The failure of chmod is a permission issue, due to a strange ACL
> inherited from Windows. However I can't explain the failure.
> 853 315868 [main] chmod 2108 normalize_posix_path: src tg.pl
> 833 316701 [main] chmod 2108 cwdstuff::get: posix /cygdrive/h/tmp
> 919 317620 [main] chmod 2108 cwdstuff::get: (/cygdrive/h/tmp) = cwdstuff::get (0x22EAD0, 260, 1, 0), errno 0
> 833 318453 [main] chmod 2108 normalize_posix_path: /cygdrive/h/tmp/tg.pl = normalize_posix_path (tg.pl)
> 855 319308 [main] chmod 2108 mount_info::conv_to_win32_path: conv_to_win32_path (/cygdrive/h/tmp/tg.pl)
> 851 320159 [main] chmod 2108 mount_info::cygdrive_win32_path: src '/cygdrive/h/tmp/tg.pl', dst 'h:\tmp\tg.pl'
> 833 320992 [main] chmod 2108 set_flags: flags: binary (0x2)
> 829 321821 [main] chmod 2108 mount_info::conv_to_win32_path: src_path /cygdrive/h/tmp/tg.pl, dst h:\tmp\tg.pl, flags
> 0x22, rc 0
> 1473 323294 [main] chmod 2108 symlink_info::check: not a symlink
> 949 324243 [main] chmod 2108 symlink_info::check: 0 = symlink.check (h:\tmp\tg.pl, 0x22E790) (0x22)
> 844 325087 [main] chmod 2108 path_conv::check: this->path(h:\tmp\tg.pl), has_acls(1)
> 1039 326126 [main] chmod 2108 build_fh_pc: fh 0x61156018
> 857 326983 [main] chmod 2108 fhandler_base::open: (h:\tmp\tg.pl, 0x110000)
> 1647 328630 [main] chmod 2108 seterrno_from_win_error: /netrel/src/cygwin-1.5.18-1/winsup/cygwin/fhandler.cc:666
> windows error 5
> 1109 329739 [main] chmod 2108 geterrno_from_win_error: windows error 5 == errno 13
> 819 330558 [main] chmod 2108 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):307 val 13
> 814 331372 [main] chmod 2108 fhandler_base::open: C0000022 = NtCreateFile (0x0, E0100, h:\tmp\tg.pl, io, NULL, 0, 7,
> 1, 4400, NULL, 0)
> 1090 332462 [main] chmod 2108 fhandler_base::open: 0 = fhandler_base::open (h:\tmp\tg.pl, 0x110000)
> 923 333385 [main] chmod 2108 fhandler_base::open_fs: 0 = fhandler_disk_file::open (h:\tmp\tg.pl, 0x10000)
> 1110 334495 [main] chmod 2108 chmod: -1 = chmod (tg.pl, 0x1B0)
> ~/tmp $ cacls tg.pl
> h:\tmp\tg.pl EU\fischron:C
> See also Capture-1.jpg in http://cygwin.com/ml/cygwin/2005-07/msg00688.html
I can't explain it even less. Did you reproduce the problem? I just
tried it by creating a file with only one ACE, which has the two bits
for "change permissions" and "take ownership" removed. But when calling
chmod on the file, it works as expected. I've also tried the same with
a parent directory with only the minimum nuber of entries and with the
above bits removed in the "CREATOR OWNER" entry (well, you never know...).
To no avail. chmod doesn't complain.
> Now there are a couple of strange things
> 1) According to
> An object's owner implicitly has WRITE_DAC access to the object.
> So perhaps the problem is WRITE_OWNER (is it needed for chmod?)
Actually no. Right now, query_write_control is used in every function
which changes the ACL in one way or the other (fchmod, fchown, facl).
If that's somehow really a problem, we could start differing between
query_write_control and, say, query_write_owner. Unless it's *evidently*
the problem, I'd rather do without it, though.
> 2) The user is also in the Admins group,
> $ id
> uid=121833(fischron) gid=10513(mkgroup_l_d)
> So he should have full access from the DACL (see above),
> as well as (most likely) from the Restore and Backup privileges that are
> usually given to Admins.
> And he was able to edit the file security settings in the Windows GUI.
> So I can't explain the failure. It may be due to slight differences between
> the semantics of CreateFile and NtCreateFile.
> (Is http://www.osronline.com/lists_archive/ntdev/thread5377.html correct ?)
I don't know, but since we're using FILE_OPEN_FOR_RECOVERY anyway, we're
on the safe side.
> XP Home is not a good platform to investigate more and go to the
> bottom of this.
Do you know about
> I notice that write_sd will retry opening the file (not sure why) with CreateFile.
Not quite. It only tries to open the file if either the incoming handle
is NULL, or if NtSetSecurityObject failed, for instance, if the incoming
handle is a R/O handle.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:firstname.lastname@example.org
Red Hat, Inc.
More information about the Cygwin-developers