From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,400599f96e15af9b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-02 15:39:58 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!193.174.75.178!news-fra1.dfn.de!news.rwth-aachen.de!news.uni-stuttgart.de!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: GNAT: Setting SIGPIPE to SIG_IGN Date: Tue, 03 Sep 2002 00:39:58 +0200 Organization: Enyo -- not your organization Message-ID: <87sn0suibl.fsf@deneb.enyo.de> References: <87ofbj5q0r.fsf@deneb.enyo.de> <3D71318A.10909@cogeco.ca> <87lm6maubz.fsf@deneb.enyo.de> <3D72CC97.7000805@cogeco.ca> NNTP-Posting-Host: deneb.enyo.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: cygnus.enyo.de 1031006393 2733 212.9.189.171 (2 Sep 2002 22:39:53 GMT) X-Complaints-To: abuse@enyo.de NNTP-Posting-Date: 2 Sep 2002 22:39:53 GMT Cancel-Lock: sha1:fEPOqPZ9LXE3QUL8+YEvIqXhsQs= Xref: archiver1.google.com comp.lang.ada:28670 Date: 2002-09-02T22:39:53+00:00 List-Id: "Warren W. Gay VE3WWG" writes: > Is there anything useful you can learn from the "GNAT compensation" > that might help? > I'm afraid I don't see an easy solution. I think the approach > I would take is to attempt to solve the "problematic side effects" in > the "tasking run-time library". Ugh, I can't do that. If tasking is activated, setuid(2) and similar system calls do not work reliable on GNU/Linux: Credentials are thread attributes, not process attributes as required. And there's somethign which makes matters even worse: The pthreads library uses signals for communication with the management thread, and if I change the credentials, the signals cannot be delivered any longer because the permission check fails, and the program just stops. This problem is triggered not only by the active use of tasking, it's sufficient to declare a single protected object. > But this probably doesn't work well for a project that must "port" > to multiple platforms (you haven't said much about the project > requirements), I'd like to have as few as GNU/Linux dependencies as possible. In fact, last weekend, I've made some changes (see my other message about C expression evaluation using autoconf) which should port my little pet project to any POSIX platform on which GNAT binaries can run. > or port to many future releases of Linux. Linux isn't the problem here, it's the threading implementation in GNU libc. I wouldn't have to face this problem if I was using FSU Threads, for example, or if I'd wait a few months (years?) until the GNU libc implementation is conforming to POSIX. > (One possibly useless suggestion is to try FreeBSD instead ;-) Perhaps after the first big security incident Debian has to experience. ;-) > Beyond that, I can't think of any further useful advice. I do > believe that you do have an interesting problem. Well, fortunately my fundamental assumption is wrong: signal handlers are not thread specific, although signals are always thread-specific (which differs from what POSIX says). As a result, I can call signal(SIGPIPE, SIG_IGN) during elaboration. Case closed. (Well, I better write a test case for that, but looking at the actual source code, I think this should work, and all the complexity isn't required.)