Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Message-ID: <3B76C44A.90202@ece.gatech.edu> Date: Sun, 12 Aug 2001 14:00:42 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin-developers AT cygwin DOT com Subject: Re: outstanding issues blocking new release? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > 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.