This is the mail archive of the cygwin 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: cacls combination problem in 1.7.35, merging privs of existing file & privs of process


On Jun 23 12:09, Corinna Vinschen wrote:
> Hi John,
> [...]
> And of course your user account is different from your primary group.
> They can only ever be identical on non-domain mamber machines when using
> the "Microsoft Accounts", where you login with your email address.
> 
> >     C:\Users\johnru>wmic group where name='Domain Users' get sid
> >     SID
> >     S-1-5-21-25853599-488532567-929701000-513
> > 
> > >
> > > Original cacls of file try2.txt:
> > >     try2.txt INTSURG\johnru:(R,W,D,WDAC,WO)
> > >              INTSURG\Domain Users:(R)
> > >              Everyone:(R)
> > >              NT AUTHORITY\SYSTEM:(F)
> > >              BUILTIN\Administrators:(F)
> > > Cacls after vi open & write back out (":wq")
> > >     try2.txt INTSURG\johnru:(DENY)(S,X)
> > >              INTSURG\johnru:(R,W,D,WDAC,WO)
> > >              INTSURG\Domain Users:(RX,W)
> > >              Everyone:(R)
> > >              NT AUTHORITY\SYSTEM:(RX,W)
> > >              BUILTIN\Administrators:(RX,W)
> 
> After I set up a directory with your permissions, I can reproduce this.
> I have an idea what the problem is, but I have to debug this further.
> Stay tuned.

No, it's not what I thought.  This is a problem with the default
settings of vi.  It's not a problem when using vim with default
settings.  Try the same with vim instead of vi.  /usr/bin/vi is a
"small" version of vim, while /usr/bin/vim is a "huge" version.  They
are build with different build time options, just as on Fedora Linux, so
they behave slightly different.

However, there appears to be a bug in vim.

At "wq!", huge vim saves the file like this:

- open edited file
- write file content
- set UNIX perms via chmod(2).  This results in the "broken" permissions
  with the additional user deny ACE and rwx perms for the group.  This is
  expected, nothing to worry about.  Yet.
- set the ACL via acl(2).  This reverts the permissions to the original
  permissions.  All is well.

Small vi saves like this:

- open backup file (same as edited file, plus trailing '~')
- copy edited file content to backup file
- set UNIX perms on backup file via chmod(2)
- set ACL via acl(2) on backup file.  Now the backup file has the
  original perms of the edited file.
- open edited file
- write file content
- set UNIX perms via chmod(2).  Now perms are "broken" as above.
- And now, because a certain flag in vi is set ("backupcopy" is set
  to "yes"), vi *skips* writing the ACL to the original file, see
  fileio.c, line 4702ff:

    #ifdef HAVE_ACL
	/* Probably need to set the ACL before changing the user (can't set the
	 * ACL on a file the user doesn't own). */
	if (!backup_copy)
	    mch_set_acl(wfname, acl);
    #endif

So it turns out that this flag, "backupcopy", when set to "yes" as is
the default when running vi, breaks ACLs in certain cases.  In vim the
flag is set to "auto", which apparently translates to "no", usually.

I think this is a bug in vim.  The `if (!backup_copy)' is wrong.  It
should always try to write the ACL on systems supporting them.

But for the time being, there are at least three easy workarounds:

- Create a ~/.virc file with this line:

   set backupcopy=no

- Always run "vim", rather than "vi".

- Add an alias so that when you run vi, you actually start vim:

   alias vi=vim


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgp__wN9L0AMX.pgp
Description: PGP signature


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