From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6927 invoked by alias); 31 May 2005 17:54:44 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6883 invoked by uid 22791); 31 May 2005 17:54:36 -0000 Received: from c-66-30-17-189.hsd1.ma.comcast.net (HELO cgf.cx) (66.30.17.189) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 31 May 2005 17:54:36 +0000 Received: by cgf.cx (Postfix, from userid 201) id 02A0213CA7E; Tue, 31 May 2005 13:54:34 -0400 (EDT) Date: Tue, 31 May 2005 21:03:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: RFC: Check permissions of .gdbinit files Message-ID: <20050531175433.GA7386@trixie.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org References: <20050530185201.GA29332@nevyn.them.org> <20050530224200.GB2727@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00666.txt.bz2 On Tue, May 31, 2005 at 08:46:03AM +0300, Eli Zaretskii wrote: >> Date: Mon, 30 May 2005 18:42:00 -0400 >> From: Daniel Jacobowitz >> Cc: gdb-patches@sourceware.org >> >> Bother; I thought about the portability for a while, but didn't quite >> consider this. We're still OK though - the whole thing is surrounded >> by HAVE_GETUID, and MinGW does not have GETUID, if I understand >> correctly. > >Maybe, I don't know. Isn't the MinGW port linked against some >library, such as libgw32c.a, that implements more Posix stuff? MinGW does not have getuid(). Or, at least the version that I have checked out doesn't have it. It is possible to emulate getuid on WinNT+ and it is possible to fill in all of the fields in st_mode with reasonable things but, AFAIK, Mingw's implementation doesn't do this. >In any case, the other issue still remains: if they do have getuid and >S_IWOTH, non-readonly files will be reported world-writable. So I'd >suggest to either disable this feature entirely on Windows platforms, >or write a Windows specific code that uses the Win32 API to get file >ownership (GetSecurityInfo or some such). Did anyone read Ulrich Drepper's recent rant about this kind of thing? :-) Are you implying that we should defend against the day when mingw starts exporting getuid? If we're postulating that getuid might exist someday can't we just postulate that st_mode has been fixed at the same time? cgf