From owner-freebsd-bugs  Mon Feb 17 14:00:03 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id OAA18466
          for bugs-outgoing; Mon, 17 Feb 1997 14:00:03 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id OAA18446;
          Mon, 17 Feb 1997 14:00:01 -0800 (PST)
Date: Mon, 17 Feb 1997 14:00:01 -0800 (PST)
Message-Id: <199702172200.OAA18446@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: bin/2747: at cannot be run in an atjob
Reply-To: j@uriah.heep.sax.de (J Wunsch)
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR bin/2747; it has been noted by GNATS.

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. ;-)