From owner-freebsd-bugs  Wed Mar 25 03:40:03 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA23441
          for freebsd-bugs-outgoing; Wed, 25 Mar 1998 03:40:03 -0800 (PST)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA23425;
          Wed, 25 Mar 1998 03:40:01 -0800 (PST)
          (envelope-from gnats)
Date: Wed, 25 Mar 1998 03:40:01 -0800 (PST)
Message-Id: <199803251140.DAA23425@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Stephen McKay <syssgm@dtir.qld.gov.au>
Subject: Re: bin/6124: Getting md5 to reset access times. 
Reply-To: Stephen McKay <syssgm@dtir.qld.gov.au>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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

From: Stephen McKay <syssgm@dtir.qld.gov.au>
To: freebsd-gnats-submit@freebsd.org
Cc: syssgm@dtir.qld.gov.au
Subject: Re: bin/6124: Getting md5 to reset access times. 
Date: Wed, 25 Mar 1998 21:31:39 +1000

 On Wednesday, 25th March 1998, David Malone wrote:
 
 > If you are using md5 to checksum a load of files you probably
 > don't want all the access times changed. This is a small patch
 > which adds a "-r" flag which resets the access times to what
 > they were before the file was checksumed.
 
 The updated manual page should point out that resetting the access time
 updates the inode change time.  For me the inode change time is much
 more interesting than the access time since dump checks ctime as well as
 mtime to determine if a file has changed, and since hackers leave more
 interesting footprints in ctime stamps than atime stamps.
 
 And that's where the story should stop, except I found interesting stuff
 when verifying my facts for this note.  FreeBSD allows a user to set an
 arbitrary access time on a file without disturbing the mtime or ctime!
 To do this, pass -1 for the mtime in utime().  That translates to
 setting tv_sec = -1 in the appropriate element for utimes().
 
 This works because VNOVAL == -1 and ufs_setattr() in ufs_vnops.c sets
 IN_ACCESS (since atime.tv_sec != VNOVAL) but not IN_CHANGE and IN_UPDATE
 (because mtime.tv_sec == VNOVAL).  Thus, ffs_update() will happily set
 the access time to the specified value and leave the other two time
 stamps alone.
 
 So, is this a bug like I think it is?  It doesn't work like this under
 Solaris or Digital Unix.  Is it a security hole?  I can't think of an
 exploit yet...
 
 Regardless, the utime and utimes manual pages need some updating, which
 I'm happy to do once the proper behaviour is defined.
 
 >+ 		if( times_ok ) {
 >+ 			TIMESPEC_TO_TIMEVAL(&tv[0], &sb.st_atimespec);
 >+ 			TIMESPEC_TO_TIMEVAL(&tv[1], &sb.st_mtimespec);
 >+ 
 >+ 			utimes(argv[optind],tv);
 >+ 		}
 
 This interesting use of TIMESPEC_TO_TIMEVAL may be of value in the future,
 but ffs_update() only uses the tv_sec portion, and throws the rest away.
 
 Stephen.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message