Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3DD8B7F3.6070100@csgsystems.com> Date: Mon, 18 Nov 2002 10:50:43 +0100 From: Christian Mueller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: .rhosts on W2K w/o ntsec Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) >> The reason for this is obvious: I turned off ntsec, thus the >> .rhosts file is owned by whoever starts rshd (probably SYSTEM >> because I run it as a service). I'm running Cygwin on W2K/NTFS; >> my CYGWIN environment variable is "ntea nontsec". > Have you considered leaving ntsec on in the service environment but > turning it off in yours, after you get in? > Pierre Thanks for the reply! Yes, I did consider it but I didn't really follow up on this idea because this would mean that all files created by subsequent processes like rsync would end up using ntsec and files being read would have the wrong permissions (i.e. from ntsec, not ntea). Unless, of course, I turn ntsec off again as soon as ruserok() has completed. The only way to do this would be in /etc/profile. Is this safe, i.e. will Cygwin see the environment changing and turn off ntsec for *all* subsequent syscalls and processes, even after forking, setting new userids, ....? Another problem would be that other services which don't start shells such as the IPC daemon, apache, etc. would end up using ntsec. Wouldn't it be a good idea to store uid and gid in the extended attributes as well and use them if ntsec is turned off? At least for me this would be the perfect solution.... Cheers, --Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/