Date: Mon, 17 Sep 2001 19:16:57 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: arch@FreeBSD.org, freebsd-standards@bostonradio.org Cc: Bruce Evans <bde@FreeBSD.org>, Garrett Wollman <wollman@FreeBSD.org> Subject: Re: Fixing chown(8) and friends to handle symlinks properly Message-ID: <20010917191657.A19072@sunbay.com> In-Reply-To: <20010913202742.C2458@sunbay.com>; from ru@FreeBSD.org on Thu, Sep 13, 2001 at 08:27:42PM %2B0300 References: <20010913202742.C2458@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi!
Unless I hear from somebody that they are wishing to review
this patch, I will take it as if noone currently has enough
spare time to review this, and will just commit this patch
on Thursday, 20th. :-)
Thanks,
On Thu, Sep 13, 2001 at 08:27:42PM +0300, Ruslan Ermilov wrote:
> [Bcc'ed to -current in a hope for a more wider auditory]
>
> The attached patch fixes the handling of symlinks in chown(8)
> and chgrp(1). It is currently broken in many different ways.
> Basically, it is broken because -h is not supported with -RH
> or -RL. The actual problem lies in the depths of the fts(3)
> implementation, in particular, how the `fts_stat' is getting
> initialized. The trick in supporting roughly any combination
> of command line flags ([-h] [-R [-H | -L | -P]]) was to avoid
> looking into the `fts_stat' (as we don't know whether it is
> from lstat(2) or stat(2)), and just call chown(2) or lchown(2)
> as appropriate. Although it may seem as a big performance
> degradation, in fact it isn't, as kernel doesn't modify the
> inode if nothing is to be changed.
>
> This work is based on the latest POSIX drafts, and the
> superior NetBSD implementation (which I had to fix in a
> number of cases anyway, in particular, handling of dead
> symlinks in the -h case).
>
> The new algorithm of handling a symlink encountered during
> a file tree traversal works as follows:
>
> +-------------+-------------------------------------------------+
> | Options | Action |
> +-------------+-------------------------------------------------+
> | -- | chown |
> | -h | lchown |
> | | Notes: only FTS_SL symlinks may end up here |
> +-------------+-------------------------------------------------+
> | -RP | SKIP |
> | -RP -h | lchown |
> | | Notes: only FTS_SL symlinks may end here |
> +-------------+-------------------------------------------------+
> | -RH | SKIP |
> | -RH -h | lchown |
> | | Notes: both FTS_SL and FTS_SLNONE symlinks |
> | | may end up here. FTS_SLNONE's are deadlinks |
> | | specified as command line arguments |
> +-------------+-------------------------------------------------+
> | -RL | SKIP |
> | -RL -h | lchown |
> | | Notes: only FTS_SLNONE symlinks may end up here |
> +-------------+-------------------------------------------------+
>
> Or, in a more compact form:
>
> : if symlink {
> : if -R
> : -h ? lchmod : SKIP
> : else
> : -h ? lchmod : chmod
> : } else
> : chmod
>
> For the testing purposes, I'd suggest creating the following
> structure, which should be self-explaining:
>
> afile
> alink -> afile
> deadlink -> nofile
> dir
> adir -> dir
> dir/afile
> dir/alink -> afile
> dir/deadlink -> nofile
>
> PLEASE TEST THIS PATCH THROUGHLY!
>
> NOTE: This implementation is still not quite POSIX compliant, as
> the latter says to follow a symlink (in the -R case) only if it
> points to an object of type directory. Our fts(3) routines are
> unable of doing this.
>
> If this patch is accepted, I'm going to revisit and fix the rest
> of the fts(3) utilities that are listed on the symlink(7) manpage.
--
Ruslan Ermilov Oracle Developer/DBA,
ru@sunbay.com Sunbay Software AG,
ru@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010917191657.A19072>