Mail Archives: cygwin-developers/2001/08/12/14:00:46
> 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.
- Raw text -