Re: chown

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

Corinna Vinschen wrote:
> 
> On Apr 15 12:11, Pierre A. Humblet wrote:
> > The problem is that I won't be privileged until write_sd.
> > It may be better to first call with query_read_control and to
> > retry in write_sd.
> >
> > I am wondering if we need a CreateFile with FILE_FLAG_BACKUP_SEMANTICS
> > or if a simple DuplicateHandle would also work, after becoming privileged.
> 
> You could give it a test.  But actually I don't understand the problem.
> What does it save us?  The CreateFile fails not because
> FILE_FLAG_BACKUP_SEMANTICS is set, but because WRITE_OWNER and
> WRITE_DAC is requested.  And you can't add these access modes by a
> call to DuplicateHandle.

I tried this:

/> touch aaa bbb
/> ls -l aaa bbb
-rw-r--r--    1 PHumblet Clearuse        0 Apr 15 12:34 aaa
-rw-r--r--    1 PHumblet Clearuse        0 Apr 15 12:34 bbb
/> chown testuser bbb
/> chown phumblet:544 aaa bbb
/> ls -l aaa bbb
-rw-r--r--    1 PHumblet Administ        0 Apr 15 12:34 aaa
-rw-r--r--    1 PHumblet Administ        0 Apr 15 12:34 bbb

Note that I could chown bbb back to PHumblet because I became
privileged while changing the group of aaa.
The point is that the initial open of bbb worked. 
So it looks like FILE_FLAG_BACKUP_SEMANTICS is not needed.
(my understanding was that FILE_FLAG_BACKUP_SEMANTIC is needed to open a
 file with WRITE_OWNER without having an ACE for that, by using the 
 privilege, but it looks like it doesn't work the way I thought.)

Why can't we set WRITE_OWNER and WRITE_DAC with DuplicateHandle?
It has a dwDesiredAccess argument.

> > Also BackupWrite was not atomic, the ACL would change while the owner
> > didn't. Do you know if NtSetSecurityObject is atomic? If so, the test
> > if (res == 1)
> >     {
> >       BOOL dummy;
> >       cygpsid owner;
> > could be removed.
> 
> I'd love to remove it.  I have no idea if NtSetSecurityObject is atomic,
> though.  I'd guess so but knowledge would require documentation...

I looked up the acl after the failed chown. It hasn't changed.
So the call looks atomic.
 
> > P.S.: I have just updated in cvs and saw your fresh change.
> > Now CreateFile might be called up to 3 times.
> > An alternative is to become privileged before the initial
> > open, but that won't work with fchown
> 
> Why not?  The code to set SE_RESTORE_NAME could easily be moved out
> of write_sd and into fhandler_disk_file's fchown, fchmod and facl
> methods.  That would allow to reduce fchown and fchmod back to
> just calling open_fs with query_write_control since that's required
> for that functionality anyway.

Right, I had in mind the fchown system call, not the method.
The file is already opened without appropriate access, so we need
to get privileged and retry, somewhere.
At this point the simplest strategy (if it works) is to open with
query_read_control (if not yet opened) and duplicate the handle
in write_sd, after becoming privileged. It covers all cases.

Pierre