From thompson@tgsoft.com  Sat Feb 15 19:22:09 1997
Received: from squirrel.tgsoft.com (squirrel.tgsoft.com [207.167.64.183])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA08911
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 15 Feb 1997 19:22:05 -0800 (PST)
Received: (from thompson@localhost) by squirrel.tgsoft.com (8.8.3/8.6.12) id TAA15126; Sat, 15 Feb 1997 19:22:48 -0800 (PST)
Message-Id: <199702160322.TAA15126@squirrel.tgsoft.com>
Date: Sat, 15 Feb 1997 19:22:48 -0800 (PST)
From: mark thompson <thompson@tgsoft.com>
Reply-To: thompson@tgsoft.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: at cannot be run in an atjob
X-Send-Pr-Version: 3.2

>Number:         2747
>Category:       bin
>Synopsis:       cannot submit at jobs from within an at job
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    davidn
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 15 19:30:02 PST 1997
>Closed-Date:    Fri Jun 23 08:06:57 PDT 2000
>Last-Modified:  Fri Jun 23 08:07:29 PDT 2000
>Originator:     mark thompson
>Release:        FreeBSD 2.2
>Organization:
T & G Software <tgsoft>
>Environment:
2.1.x and 2.2
>Description:

You cannot submit an at job from within an at job, since the submitted
job will have the wrong mail address, and atrun will reject it. The
comments suggest that the code in question (see below) is a hangover
from an earlier day, and no longer appropriate.

>How-To-Repeat:

Have an at job that submits itself. Run the at job as someone other
than root. The submitted job will not run.

>Fix:
	
--- at.c	Mon Oct 23 22:09:54 1995
+++ at.c.new	Sat Feb 15 19:15:28 1997
@@ -298,12 +298,9 @@
     if((fp = fdopen(fdes, "w")) == NULL)
 	panic("Cannot reopen atjob file");
 
-    /* Get the userid to mail to, first by trying getlogin(), which reads
-     * /etc/utmp, then from LOGNAME, finally from getpwuid().
+    /* Get the userid to mail to, first by LOGNAME, then from getpwuid().
      */
-    mailname = getlogin();
-    if (mailname == NULL)
-	mailname = getenv("LOGNAME");
+    mailname = getenv("LOGNAME");
 
     if ((mailname == NULL) || (mailname[0] == '\0') 
 	|| (strlen(mailname) > 8) || (getpwnam(mailname)==NULL))
>Release-Note:
>Audit-Trail:

From: Mike Pritchard <mpp>
To: thompson@tgsoft.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/2747: at cannot be run in an atjob
Date: Sat, 15 Feb 1997 23:04:09 -0800 (PST)

 mark thompson wrote:
 > 
 > You cannot submit an at job from within an at job, since the submitted
 > job will have the wrong mail address, and atrun will reject it. The
 > comments suggest that the code in question (see below) is a hangover
 > from an earlier day, and no longer appropriate.
 
 Be careful around this code.  If I remember correctly from the last
 time I mucked around in there, there are security implications
 with the whole section of code.
 -- 
 Mike Pritchard
 mpp@FreeBSD.org
 "Go that way.  Really fast.  If something gets in your way, turn"

From: j@uriah.heep.sax.de (J Wunsch)
To: thompson@tgsoft.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/2747: at cannot be run in an atjob
Date: Sun, 16 Feb 1997 20:48:18 +0100

 As mark thompson wrote:
 
 > You cannot submit an at job from within an at job, since the submitted
 > job will have the wrong mail address, and atrun will reject it. The
 
 People might consider this a feature. :-) So you can't defeat a
 cron.deny entry with just an at.allow one.
 
 > comments suggest that the code in question (see below) is a hangover
 > from an earlier day, and no longer appropriate.
 
 No, the comments don't suggest this to me, sorry.
 
 > -    /* Get the userid to mail to, first by trying getlogin(), which reads
 > -     * /etc/utmp, then from LOGNAME, finally from getpwuid().
 > +    /* Get the userid to mail to, first by LOGNAME, then from getpwuid().
 >       */
 > -    mailname = getlogin();
 > -    if (mailname == NULL)
 > -	mailname = getenv("LOGNAME");
 > +    mailname = getenv("LOGNAME");
 
 No, sorry, the preference of getlogin() over LOGNAME is a normal
 sequence.  getlogin() is much harder to fake.
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)

From: mark thompson <thompson@tgsoft.com>
To: mpp@freefall.freebsd.org
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/2747: at cannot be run in an atjob
Date: Sun, 16 Feb 1997 20:37:59 -0800 (PST)

    From: Mike Pritchard <mpp@freefall.freebsd.org>
    Date: Sat, 15 Feb 1997 23:04:09 -0800 (PST)
 
    mark thompson wrote:
    > 
    > You cannot submit an at job from within an at job, since the submitted
    > job will have the wrong mail address, and atrun will reject it. The
    > comments suggest that the code in question (see below) is a hangover
    > from an earlier day, and no longer appropriate.
 
    Be careful around this code.  If I remember correctly from the last
    time I mucked around in there, there are security implications
    with the whole section of code.
 
 Well, i cannot disagree that there are security implications, but the
 only thing removed is the call to getlogin, which *clearly* is not going
 to be correct within an atjob unless atrun starts doing a setlogin, and
 i was unwilling to contemplate messing with atrun.
 
 Since it *should* be possible to submit an at job from within an at job
 (works on every other unix i've tried), since the name will come from
 getpwuid(real_uid) if LOGNAME is not set (atrun sets it), and since
 atrun tries real hard to prevent spoofing, i say that this is an
 anachronism and i think it should go.
 
 SO THERE ;-)
 
 -mark
 

From: mark thompson <thompson@tgsoft.com>
To: joerg_wunsch@uriah.heep.sax.de
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/2747: at cannot be run in an atjob
Date: Mon, 17 Feb 1997 05:12:03 -0800 (PST)

    Date: Sun, 16 Feb 1997 20:48:18 +0100
    From: j@uriah.heep.sax.de (J Wunsch)
 
    As mark thompson wrote:
 
    > You cannot submit an at job from within an at job, since the submitted
    > job will have the wrong mail address, and atrun will reject it. The
 
    People might consider this a feature. :-) So you can't defeat a
    cron.deny entry with just an at.allow one.
 
 I take it from the ascii winky that you are joking.
 
    > comments suggest that the code in question (see below) is a hangover
    > from an earlier day, and no longer appropriate.
 
    No, the comments don't suggest this to me, sorry.
 
    > -    /* Get the userid to mail to, first by trying getlogin(), which reads
    > -     * /etc/utmp, then from LOGNAME, finally from getpwuid().
    > +    /* Get the userid to mail to, first by LOGNAME, then from getpwuid().
    >       */
    > -    mailname = getlogin();
    > -    if (mailname == NULL)
    > -	mailname = getenv("LOGNAME");
    > +    mailname = getenv("LOGNAME");
 
    No, sorry, the preference of getlogin() over LOGNAME is a normal
    sequence.  getlogin() is much harder to fake.
 
 The comment 'which reads /etc/utmp' does not suggest that it is a
 holdover from previous times? In any case, let us assume just for a
 moment that the user does set LOGNAME, then run at to try to spoof the
 system. WHAT HARM DOES THAT DO? The mailname is the mailbox that the job
 log is sent to - and atrun verifies that it matches the owner of the
 submitted job in any case (that's why this fails in the first place).
 
 -mark
 
 ps. Now mind you - atrun has a buffer size overflow problem in the
 fscanf that reads this... [HMMM... (looks at 2.2) no, the buffer
 overflow is still there - AND - someone removed the check of mailname
 against the file's owner! This seems to be going downhill. ]
 

From: j@uriah.heep.sax.de (J Wunsch)
To: thompson@tgsoft.com (mark thompson)
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/2747: at cannot be run in an atjob
Date: Mon, 17 Feb 1997 22:29:26 +0100

 As mark thompson wrote:
 
 >    People might consider this a feature. :-) So you can't defeat a
 >    cron.deny entry with just an at.allow one.
 > 
 > I take it from the ascii winky that you are joking.
 
 Yep.
 
 >    No, sorry, the preference of getlogin() over LOGNAME is a normal
 >    sequence.  getlogin() is much harder to fake.
 > 
 > The comment 'which reads /etc/utmp' does not suggest that it is a
 > holdover from previous times?
 
 A holdover from Linux, where our at(1) originates from.
 
 I think atrun(8) should rather call setlogin(), the at(1) falling over
 the missing login name is only one examle of a failing program --
 there might be more of them.
 
 > ps. Now mind you - atrun has a buffer size overflow problem in the
 > fscanf that reads this...
 
 Umpf.
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)
Responsible-Changed-From-To: freebsd-bugs->davidn 
Responsible-Changed-By: davidn 
Responsible-Changed-When: Tue Feb 18 16:34:25 EST 1997 
Responsible-Changed-Why:  
I'll take care of it as part of the login.conf revision. 

From: mark thompson <thompson@tgsoft.com>
To: joerg_wunsch@uriah.heep.sax.de
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/2747: at cannot be run in an atjob
Date: Tue, 18 Feb 1997 08:15:39 -0800 (PST)

    Date: Mon, 17 Feb 1997 22:29:26 +0100
    From: j@uriah.heep.sax.de (J Wunsch)
 
    >    No, sorry, the preference of getlogin() over LOGNAME is a normal
    >    sequence.  getlogin() is much harder to fake.
    > 
 
    I think atrun(8) should rather call setlogin(), the at(1) falling over
    the missing login name is only one examle of a failing program --
    there might be more of them.
 
    > ps. Now mind you - atrun has a buffer size overflow problem in the
    > fscanf that reads this...
 
    Umpf.
 
 Sigh. You are certainly right; i have been trying to avoid working on
 atrun. 
 
 To do a setlogin i have to create a session. While i am at it, are there
 other portions of the user's environment are not being emulated that
 should be? 
 
 The mailname being passed to atrun... do we just trust it, or should we
 verify that, if it is a user's login (might be an alias!) that the uid
 matches the submitter? Or do we ignore it and mail to the submitter?
 
 -mark
State-Changed-From-To: open->feedback 
State-Changed-By: nbm 
State-Changed-When: Fri Dec 17 01:30:01 PST 1999 
State-Changed-Why:  
It seems that this is no longer a problem, probably following dima's 
addition of setlogin use to atrun.c, revision 1.11.  Can you confirm 
this? 
State-Changed-From-To: feedback->closed 
State-Changed-By: nbm 
State-Changed-When: Fri Jun 23 08:06:57 PDT 2000 
State-Changed-Why:  
Feedback timed out, and this problem doesn't seem to exist anymore. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=2747 
>Unformatted:
