chmod suddenly ceased to work on old files - NEW FINDINGS

Corinna Vinschen corinna-cygwin@cygwin.com
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.
> http://cygwin.com/ml/cygwin/2005-07/msg00689.html
> 
> 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
>              EU\MUC-ADM-FileOperators-Home-L:C
>              VORDEFINIERT\Administrators:F
>              EU\MUC-ADM-FileOperators-L:F
> 
> 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
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/security_descriptors.asp
> 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,
> http://cygwin.com/ml/cygwin/2005-07/msg00476.html
> $ id
> uid=121833(fischron) gid=10513(mkgroup_l_d)
> groups=544(Administrators),545(Users),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
HKLM/SYSTEM/ControlSet001/Control/ProductOptions/ProductSuite ?

> 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.



More information about the Cygwin-developers mailing list