From owner-freebsd-bugs@FreeBSD.ORG Tue Aug 8 14:50:24 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0BAE16A4FD for ; Tue, 8 Aug 2006 14:50:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D4CA43D64 for ; Tue, 8 Aug 2006 14:50:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k78EoEif086998 for ; Tue, 8 Aug 2006 14:50:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k78EoEPC086997; Tue, 8 Aug 2006 14:50:14 GMT (envelope-from gnats) Resent-Date: Tue, 8 Aug 2006 14:50:14 GMT Resent-Message-Id: <200608081450.k78EoEPC086997@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Spencer Minear Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2418216A4E0 for ; Tue, 8 Aug 2006 14:41:37 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id A913043D45 for ; Tue, 8 Aug 2006 14:41:36 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k78EfahJ030120 for ; Tue, 8 Aug 2006 14:41:36 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k78Efao3030119; Tue, 8 Aug 2006 14:41:36 GMT (envelope-from nobody) Message-Id: <200608081441.k78Efao3030119@www.freebsd.org> Date: Tue, 8 Aug 2006 14:41:36 GMT From: Spencer Minear To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: misc/101660: Restore does not preserve uid and gid on short symlinks X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2006 14:50:24 -0000 >Number: 101660 >Category: misc >Synopsis: Restore does not preserve uid and gid on short symlinks >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 08 14:50:13 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Spencer Minear >Release: 6.0 >Organization: Securecomputing Corp. >Environment: Running on our SecureOS variant of 6.0 >Description: The problem appears to come from the fact that short link information is stored in the inode (header data in the case of a restore file), and for longer links the link information is stored in the data. In the tape.c:extract_file function is called to store a short link the static variable, curfile, contains information about the link being restored. Many of the attributes are extracted from curfile at the entry to the function. Later in the case IFLNK processing a call is made to getfile to obtain the data with the link value. (NOTE: I have not studied the workings of getfile so I'm conjecturing based on observation with gdb). When a short link is being processed the is no data to read. In this case getfile appears to read in the next file header in the restore file/stream and save the results in the curfile static variable. The processing then proceeds to build the symbolic link and then set it attibutes. All but two of the attributes are taken from data taht was carefully set asside on entry to the function. Those last two attributes, user id and group id, are read from the current file varible and are NOT necessarily the correct values. Note the before and aft er lists below. Before Dump alpha:Admn {76} % ls -l total 4 -r-xr-xr-x 1 a user 0 Aug 7 16:44 F lrwxr-xr-x 1 a bin 1 Aug 8 08:46 FL -> F lrwxr-xr-x 1 b bin 1 Aug 8 08:49 ThelongwaytogettoFishere -> F -rw-r--r-- 1 bin bin 54 Aug 7 07:34 fwregisterd.conf -rw-r--r-- 1 bin bin 54 Aug 7 07:34 fwregisterd.conf.bak After restore alpha:Admn {66} % ls -l total 4 -r-xr-xr-x 1 a user 0 Aug 7 16:44 F lrwxr-xr-x 1 bin bin 1 Aug 8 08:46 FL -> F lrwxr-xr-x 1 a user 1 Aug 8 08:49 ThelongwaytogettoFishere -> F -rw-r--r-- 1 bin bin 54 Aug 7 07:34 fwregisterd.conf -rw-r--r-- 1 bin bin 54 Aug 7 07:34 fwregisterd.conf.bak >How-To-Repeat: Set up a directory near the root of the file system, a file with a short name, a link with a short name and link with a long name and a few other files. Build the links using different identities so that the group owener are different. Do a dump of the containing file system, then wipe out the directory and restor. It is likely that the attributes on the short link will change to those of another file or link in the directory. >Fix: I believe that the fix for the problem is to simply save all of the relvant attributes on entry to the function and do not ever use attributes from curfile once the likes of getfile is called. >Release-Note: >Audit-Trail: >Unformatted: