Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Message-Id: <3.0.5.32.20021103142141.00815cf0@h00207811519c.ne.client2.attbi.com> X-Sender: pierre AT h00207811519c DOT ne DOT client2 DOT attbi DOT com Date: Sun, 03 Nov 2002 14:21:41 -0500 To: cygwin-developers AT cygwin DOT com From: "Pierre A. Humblet" Subject: Re: Solving ntsec problems? In-Reply-To: <20021103180437.GA19854@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 01:04 PM 11/3/2002 -0500, you wrote: >Pierre did you say that you had some patches which helped alleviate the >ntsec problems that people are complaining about? There have been fewer complains recently. Today I have seen something about XEmacs interpreting r-x as non-readonly (not a Cygwin problem ?) and something about ntsec and autotool. http://cygwin.com/ml/cygwin/2002-11/msg00067.html Interestingly that one said: "I ran the cygwin setup as my normal user, and when prompted, gave it credentials for an administrator." Compare it with what Rob said in http://cygwin.com/ml/cygwin-apps/2002-10/msg00230.html There is something fishy going on with non-privileged users. To answer your question, I have 4 security related patches on the way but I was waiting for Corinna to come back and review them, as they raise design issues. The last one will have Cygwin automatically add an entry to the internal copies of passwd and group (if needed) for the current user. I wrote it yesterday, tested it on WinMe and will test it on NT tomorrow. That will take care of domain users that don't run mkpasswd -d and then ask why their name is Administrator (but note that already with 1.3.14 such users shouldn't have permission problems). >I think we definitely need to add some logic to a postinstall script for >setup so that executables are correctly chmod'ed and directories have >the proper permission. > >It would be possible to kludge something along the line of _update_info_dir >which gets run every time a package is installed to update /bin /usr/sbin, >etc. It would add noticeably to the amount of time taken by setup as it >exits, though. I just did a: > >cd / >find bin lib usr etc -name '*.exe' | xargs chmod a+x > >and it took 27 seconds. That was after messing around with the find >command so some of the files/directories were probably already in >"cache". This is on my dual PIII 733MHZ system. There was an objection to this earlier, to the effect that users may choose to turn off x on some programs and that setup shouldn't silently turn it on again. So I'd rather offer a fixup script that users can run once explicitly to fix the current situation, and then try to insure that future installs set the correct permissions for new files. Do we know how those permissions are set? Are they set explicitly by setup, or are they based on the inheritable permissions of the parent directory (default)? If so having the "fixup script/program" set the parent directory acl properly would be the way to go. Users could control the permissions of new files (say choosing between 777 and 755) by using the Windows GUI or setfacl to set the default in the parent. One drawback of using default is that the permissions are uniform for all files in a directory, but that should be OK. Do we have directories containing both executable and non executable files? >I don't think we want to add ntsec awareness to setup.exe unless we >want to make setup installation a two step process where the setup tar >extraction relies on a cygwin DLL. It would be nice to be able to >rely on the permissions in the installation tar files being properly >preserved on extraction. See above. >Anyway, while 1.3.14 seems to have solved some problems, I'm still >concerned by the number of people struggling with ntsec issues. I'd >like to start taking active steps to solving these problems. If you see something specific, please forward it to me just in case I miss it. Pierre