From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ir9L7-0004SM-HX for garchives@archives.gentoo.org; Sun, 11 Nov 2007 09:42:50 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lAB9fwaX011903; Sun, 11 Nov 2007 09:41:58 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lAB9e8qe009648 for ; Sun, 11 Nov 2007 09:40:08 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2AB7B65894 for ; Sun, 11 Nov 2007 09:40:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 required=5.5 tests=[AWL=0.456, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSQX98xe-kag for ; Sun, 11 Nov 2007 09:40:01 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id DE3EC6588B for ; Sun, 11 Nov 2007 09:39:59 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ir9I9-0004Dv-Ub for gentoo-dev@gentoo.org; Sun, 11 Nov 2007 09:39:45 +0000 Received: from 81.168.40.136 ([81.168.40.136]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Nov 2007 09:39:45 +0000 Received: from slong by 81.168.40.136 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Nov 2007 09:39:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: Re: eselect_zenity: alpha eselect GUI Date: Sun, 11 Nov 2007 09:43:49 +0000 Message-ID: References: <20071108104813.GI5516@supernova> <20071108105454.1844a75c@blueyonder.co.uk> <20071108120742.GK5516@supernova> <20071108124333.2a3dfdc7@blueyonder.co.uk> <20071108183450.15b4a7bb@blueyonder.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 81.168.40.136 User-Agent: KNode/0.10.4 Sender: news X-Archives-Salt: 70179803-68d2-4b1f-92fa-b797a0f87fb7 X-Archives-Hash: 04831169d96528c909c53d047ecbd854 Ciaran McCreesh wrote: > On Thu, 08 Nov 2007 18:22:48 +0000 > Steve Long wrote: >> > if [[ ${UID} -ne 0 ]]; then >> > >> > We've always told people not to do that. Capabilities required by >> > eselect modules should be tested by attempting to perform the >> > action, not by some arbitrary query done on UIDs or groups. Being >> > UID 0 doesn't mean you're allowed to do something, and not being >> > UID 0 doesn't mean you're not allowed to do something. >> > >> I've always used EUID for the root check, eg: > > Which is just as bad. > No, it's better for the reason given: it doesn't require login as root. Use of ((EUID)) is also quicker. >> This won't get round capabilities (so error status should still be >> checked and the script bail with appropriate output, if it can't do >> something it's supposed to) but it's sufficient for root privilege >> check, and is better than UID which requires login as root. This >> doesn't, of course, deal with non-root users, eg where users in group >> portage are allowed to carry out a task. > > Except you absolutely never should be checking for root. You should be > checking for capabilities. > Whatever. Requiring root for certain tasks has a long history: I didn't make a value judgement, merely pointed out that there is a better method built in to BASH. Further, group membership, while not as fine-grained as ACLs or Linux Capabilities, is still a legitimate security mechanism. Just because it was invented more than ten years ago, that doesn't make it useless. >> You can check for that kind of thing with a writeable test, eg: >> [[ -w $PORTDIR ]] || die 'Write access to portage dir required" > > -w is not reliable. > How so? igli: looks pretty reliable to me. yer me too lhunath lhunath@avaria ~ $ ll /tmp/a -rw-rw-rw- 1 root root 0 2007-11-11 09:50 /tmp/a lhunath@avaria ~ $ [[ -w /tmp/a ]]; echo $? 1 lhunath@avaria ~ $ echo a > /tmp/a -bash: /tmp/a: Permission denied igli: that example is with grsec turned on making /tmp/a unwritable. so -w seems to take even grsec into account. >> Wrt signalling die, the correct way for a script to terminate on >> signal is something like this code, taken from a SIG_INT handler: >> trap INT >> kill -INT $$ >> This ensures the parent process is correctly notified. So IOW just >> kill self with the appropriate signal, ensuring any traps are cleared. > > No it isn't. Yes it is. I was talking about handling signals, which you appear to have missed. It's not common knowledge so I thought I'd share it. (For those who care about code, you can kill $$ from a subshell too, to signal the _parent_ process.) > When it comes to die, from bad implementations to good > implementations, the order goes: the original drobbins prefix die sucks > more than the original agriffis die, which sucks more than my original > signalling eselect die, which sucks more than the current signalling > paludis die. As time goes on we're finding better and better tricks to > work around bash's lack of exceptions; eselect is currently one > generation behind the best current known solution. > Thing is you never, ever post code, or discuss actual solutions at a technical level, beyond simply saying everyone else is wrong. As such I find your posts devoid of technical content, and negative. I'll leave it at that; bear in mind I won't be responding unless you actually *present* and discuss code solutions (beyond simply saying they "suck" or yet again *yawn* marketing paludis while refusing to discuss /how/ or /why/ its algorithms are better.) BTW people have implemented many correct solutions without exceptions. You clearly still have much to learn from those who came before you. -- gentoo-dev@gentoo.org mailing list