Re: chown

[Corinna Vinschen <vinschen at redhat dot com>]

On Apr 16 21:05, Pierre A. Humblet wrote:
> At 11:37 PM 4/16/2004 +0200, Corinna Vinschen wrote:
> >I've changed fhandler_base::open to use NtCreateFile now.  After some
> >head scratching and searching with google, I read that the Win32 CreateFile
> >call adds some access bits at its own will, namely the FILE_READ_ATTRIBUTES
> >and SYNCHRONIZE bits.  The latter is a problem when a user has no
> >FILE_READ_DATA permission on a file since that apparently seem to disallow
> >requesting SYNCHRONIZE. 
> >I hope I got everything right.  I'm not sure about serial I/O, since it's
> >not entirely clear to me if FILE_FLAG_OVERLAPPED is simply translatable
> >into not setting the FILE_SYNCHRONOUS_IO_NONALERT flag.
> 
> Wow, why the change to NtCreateFile? It's unlikely to be chown/chmod.

It has multiple reasons.

The first is mentioned above.  Imagine a file foo with you not being owner
and with, say, 0600 permissions.  The following works fine:

  GetFileSecurity("foo", ...);

This results in a EPERM from CreateFile:

  if (hdl = CreateFile ("foo", READ_CONTROL, ...))
    {
      GetSecurityInfo (hdl, ...);
      CloseHandle (hdl);
    }

When inspecting the situation with Filemon from sysinternals, you'll see
that GetFileSecurity exactly requests READ_CONTROL while CreateFile requests
*more* than just READ_CONTROL.  And fails, consequentally.
Therefore, if you want to use method 2, you have to use NtCreateFile directly
since it does not mess around with access bits.

The second reason is that we will go in this direction anyway.  Since 9x
is dying out, we're going to be more NT friendly in future and try to
use direct NT calls more often.  A good example is the GetVolumeInformation
call, which needs the exact root dir filename to work.  The NT equivalent
NtQueryVolumeInformationFile takes a handle to *any* file on the disk.
Using this knowledge, we could request the affected information right
after opening a file, so we spare another open/close operation on NT which
is just necessary due to the dull Win32 API.  If it takes somewhat longer
on 9x then... well... you cannot have everything, right?

The third reason is that I would have to have to revert all the changes
to chown/chmod/acl and in security.cc otherwise.  Then I better go a step
forward than back.

> Everything looks OK, I just have a few comments.  
> - Attached is a diff that streamlines the processing on 9X and when ntsec 
> is off. 

A patch?  On cygwin-developers?  And no ChangeLog?  Tsk, tsk, tsk.

> - I noticed that the fchmod method will return success even when ntea is
> present and fails, but that's inherited from the old chmod.

Grmbl, yes.  I'd so much like to remove ntea entirely but I guess that
would result in mob law coming over me on the Cygwin ML.

> -I don't see why it's necessary to add FILE_ATTRIBUTE_SYSTEM in the fchmod
> method. It should be present already.

Good question.  I don't know either at the moment.  AFAICS, chmod isn't
called from any other internal procedure so I'm wondering about that, too.

> - The new open_9x contains ntsec related stuff that could be removed.

PTC.


Corinna

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