From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 20 04:01:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE2C916A40F for ; Wed, 20 Sep 2006 04:01:47 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9AF43D45 for ; Wed, 20 Sep 2006 04:01:47 +0000 (GMT) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id k8K415cc039591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Sep 2006 21:01:06 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id k8K4153L039590; Tue, 19 Sep 2006 21:01:05 -0700 (PDT) Received: by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA21953; Tue, 19 Sep 06 20:56:49 PDT Date: Tue, 19 Sep 06 20:56:49 PDT From: perryh@pluto.rain.com (Perry Hutchison) Message-Id: <10609200356.AA21953@pluto.rain.com> To: myself@rojer.pp.ru In-Reply-To: <4510AF6D.2060809@rojer.pp.ru> References: <10609200101.AA21405@pluto.rain.com> <4510AF6D.2060809@rojer.pp.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: Symlinks on read-only FS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2006 04:01:47 -0000 > > Is the inclusion of VLNK here correct? I would think that > > only the target of the symlink should matter: if it happens > > to point onto a writable FS, the fact that the symlink itself > > is on a ROFS should not matter. > > yes, it is correct. > short symbolic links are stored in the inode itself, so if you > modify a short link, you'll be modifying metadata, which is > not allowed. it could be argued, that as long as the change is > restricted to one inode, it could be tolerable, but moreover, > if your short symbolic link is modified to be longer than fits > in inode, a disk block will need to be allocated, which would > involve a change to block map, which is certainly not desirable > for read-only mounts. So the sort of write access being validated here would be writing to the symlink itself (i.e. the definition)? I did not know that could be done. I had expected that the caller would eventually dereference the link, and write to its target. Certainly we wouldn't want to allow changing what the link itself contains if it is on a ROFS -- indeed this might not even be possible (e.g. if the FS is recorded on a CDROM).