From owner-freebsd-security Tue Nov 14 15:01:51 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA22659 for security-outgoing; Tue, 14 Nov 1995 15:01:51 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA22585 ; Tue, 14 Nov 1995 15:00:57 -0800 Received: by sequent.kiae.su id AA01987 (5.65.kiae-2 ); Wed, 15 Nov 1995 02:00:37 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 15 Nov 95 02:00:34 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.12/8.6.12) id BAA02178; Wed, 15 Nov 1995 01:29:27 +0300 To: davidg@Root.COM Cc: committers@freebsd.org, peter@freebsd.org, security@freebsd.org References: <199511141406.GAA00369@corbin.Root.COM> In-Reply-To: <199511141406.GAA00369@corbin.Root.COM>; from David Greenman at Tue, 14 Nov 1995 06:06:24 -0800 Message-Id: Organization: Olahm Ha-Yetzirah Date: Wed, 15 Nov 1995 01:29:27 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: cvs commit: CVSROOT log_accum.pl Lines: 33 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1322 Sender: owner-security@freebsd.org Precedence: bulk In message <199511141406.GAA00369@corbin.Root.COM> David Greenman writes: >>> The current behavior is not inconsistent with the manual page. It says >>>nothing about a requirement that the session *leader* must be the caller, >>>only that it affects the current session. >> >>Yes, but if it isn't leader, it affects *all* sessions, not current one >>only, it is main bug. > Sorry, Andrey, but I don't think you know what a "session" is. Sorry, it was quick attempt to say something different: I mean process group from one session. I really want to say that any root process from process group can modify its father login name. Traditionly son can't modify father resources in such way. >>As manpage additionly says, it happens "only when new session is >>being created", it assumes session leader too. > It makes no such assumption. Why? New session is being created after setsid() (no usual way to do that besides setsid()), *AND* process becomes session leader after setsid(), *SO* it assumes session leader. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849