outstanding issues blocking new release?

Charles Wilson cwilson@ece.gatech.edu
Sun Aug 12 11:00:00 GMT 2001


 > On Tue, Aug 07, 2001 at 06:38:13PM +0200, Corinna Vinschen wrote:
 >> ================================================================= 
IMPORTANT
 >>  QUESTION! 
=================================================================
 >>

 >> [...] Shall we return to propagating permissions to subfolders and
 >>  files? 
-------------------------------------------------------------------
 >>

 >>> The advantage is that native windows applications would create
 >>> files
 >> with useful permissions again.
 >>> Since 1.3.2 still propagate permissions, non-developer users
 >>> wouldn't
 >> even realize that something has changed. Even users who don't
 >> upgrade to the latest setup.exe wouldn't have the problem which
 >> Charles stumbled over. Sorry, Charles! It seems as if you has
 >> been sort of a guinea pig...
 >
 > Ok, I have tested the results and I have reverted the code to 
propagate/inherit
 >  ACEs to child objects. So the behaviour is the following now:
 >
 > - New files and folder created with Cygwin have exactly the ACEs 
corresponding
 >  to the POSIX permissions.
 >
 > - New files and folder created with native Windows apps get the 
permissions
 >  from the parent directory.
 >
 > - The NULL ACE which is used for SUID, SGID and VTX bit is never 
inherited.
 >



Okay, in a (mostly successful) attempt to clean up the mess I've made of
my installation w.r.t permission settings, inheritance, etc, I:

1) built a new setup.exe and cygwin1.dll from 20010811 CVS.
2) downloaded all the packages from a cygwin mirror to create a local repo.
3) replaced the cygwin, mingw, and w32api packages with my local
snapshots, and edited setup.ini accordingly.
4) replaced the setup.exe with my local 20010811 version.)
5) After shutting down all cygwin processes, I used windows tools to
rename D:\cygwin (my root).

6) Reinstall cygwin using my local repo
7) Painstakingly copy over my local stuff from the old installation.
Required yet more jiggering around with perms -- but only on the "old"
installation.  On the new installation, the duplicate files were created 
using "cp -a" and I never messed with their perms (or inheritance 
properties). All of this work was done under the 20010811 cygwin1.dll, 
which contains Corinna's changes above.

Result:

After about 8 hours of work, I now have a new install that seems to be
okay. (This setup.exe part of the reinstall went quickly and well.  It's 
just that I've got 600MB or so and tens of thousands of files in my 
/usr/src and /usr/local trees.  Sigh.) Perms/ACL's look good. The only 
discrepancy:

the ACL for a directory created by setup.exe is not the same as the ACL
for a directory created by mkdir() under new cygwin1.dll:

Created by setup.exe:
# file: /bin
# owner: 544
# group: 513
user::---
group::---
mask::---
other::rwx
default:mask::---

Created by mkdir:
# file: /usr/local/doc
# owner: 500
# group: 513
user::rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx

In each case, 'ls -ld' shows "drwxrwxrwx".  Newly created files 
underneath these two directories have ACLs that are identical.

It seems that setup.exe follows "behavior #2" in Corinna's description 
(because setup.exe IS a native windows app, after all).

Two related questions:
1) is the difference in directory ACLs a problem?
2) should setup.exe contain the same code that security.cc does, so that 
setup-created dirs have the same ACL as mkdir-created ones? (E.g. with 
regards to ACL's, should setup.exe behave as a cygwin app according to 
"behavior #3" in Corinna's description above?)

An unrelated question: should setup create /tmp with perms 1777 instead 
of 0777, as it currently does?

--Chuck

P.S. I did this on my newly-repaired development machine, so "I'm back", 
except for those pesky dissertation issues.





More information about the Cygwin-developers mailing list