Date: Sun, 3 May 1998 16:07:19 +0200 (MET DST) From: Wolfgang Helbig <helbig@Informatik.BA-Stuttgart.DE> To: bde@zeta.org.au (Bruce Evans) Cc: bde@FreeBSD.ORG, helbig@Informatik.BA-Stuttgart.DE, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/chown chown.c Message-ID: <199805031407.QAA17706@rvc1.informatik.ba-stuttgart.de> In-Reply-To: <199805031206.WAA20229@godzilla.zeta.org.au> from Bruce Evans at "May 3, 98 10:06:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> >> The previous commit broke this. The first victim was bsd.prog.mk,
> >> which uses a plain chown in an attempt to change the ownership of the
> >> symlinks to `dm' in /usr/games. This fails when it is done before
> >> dm is installed, or messes up the ownership of dm if dm is installed.
> >
> >Before and after r1.11 it always failes, since symlinks were ignored
> >completely by chown(8) without [-hHL], i. e. neither the symbolic
> >link nor the file linked to were affected by chown(8).
>
> Ignoring is not quite the same as failing. When symlinks didn't have
> owners, it was correct to ignore the chown(8), since following the
> link might have clobbered the owner of the target. Both following the
> link and ignoring the chown(8) are harmless in /usr/games, provided the
> target exists (the symlink targets are already owned by games.bin, and
> it just makes `ls -l' output look nicer to change the symlink ownership
> from root.bin to games.bin).
>
> >I suggest to implement the 4.4BSD behaviour as outlined in symlink(7),
> >and documented in the man page of chown(8).
>
> I suggest not. The 3 commands documented as following symlinks
> specified on the command line (chown, chgrp and file(1)), seem to
> have never actually done that in FreeBSD:
>
> 4.4Lite's file.1 documents doing it, but 4.4Lite is missing the source
> for /usr/src/usr.bin/file. It only has sources for contrib/file-3.12,
> which don't do it, at least when naively configured. Anyway, we blew
> away 4.4Lite's file.1 with a newer distribution of `file' which has a
> -L option like ls's.
>
> 4.4Lite's chown.8 conflicts with its symlink.7. The former says that
> "Symbolic links don't have owners, so unless the -H or -L option is
> set, chown on a symbolic link always succeeds and has no effect".
>
> Similarly for 4.4Lite's chgrp.1.
>
> >Let cslink and rslink be symbolic links pointing to the files
> >cpointed_to and rpointed_to respectively. Assume cslink be
> >given on the command line and rslink found during a recursive
> >traversal.
> >
> >flags affected
> >---------------------------------
> > cpointed_to
> >-h cslink,
> >-R cslink, rslink
> >-RH cpointed_to, rslink
> >-RL cpointed_to, rpointed_to
>
> OK, this is what rev.1.10 does (except for -R).
No, this is the semantics of rev 1.10:
flags affected
------------------------
none of them
-h cslink,
-R none of them
-RH cpointed_to
-RL cpointed_to, rpointed_to
> >The -h option gives complete control in the nonrecursive case, and
> >the -R[HL] options in the recursive case, if implemented as outlined above.
>
> I think -HLP should have applied without -R:
>
> -H cpointed_to
> -L cpointed_to (same as -H; already implemented in ls(1) and file(1))
> -P cslink (same as default)
> -h cslink (same as default, deprecated)
> >> 4. The correct interaction of -h with the other flags is not clear.
> >
> >According to symlink(7) -h and -R[HL] cannot be given together on
> >the command line.
>
> I can't find this.
symlink.7 seperates case 2: ``commands not traversing a file tree'' from
case 3: ``commands traversing a file tree'' and the -h flag is to be
used only for case 2. If commands optionally traverse a file tree (triggert
by -R) the behaviour should be governed by the -[HLP] options solely.
At least that's how I understand symlink.7.
> >If you agree, I'd implement the 4.4BSD suggestions (r1.11 didn't,
> >with -R alone the pointed to files were affected instead of the
> >symlinks themselves).
>
> -R actually ignores symlinks deep in the tree as well as on the
> command line. It should handle all symlinks the same (only the
> -H flag give different handling of symlinks on the command line).
> I think it should change the symlinks (NOT as in symlink.7).
So you suggest this table?
flags affected
-----------------------------------------
cslink
-h, cslink (deprecated by you)
-H, cpointed_to
-L, cpointed_to
-P, cslink
-R, cslink, rslink
-RH, cpointed_to, rslink
-RL, cpointed_to, rpointed_to
-RP, cslink, rslink
Wolfgang
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805031407.QAA17706>