Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 May 1998 11:48:53 +0200 (MET DST)
From:      Wolfgang Helbig <helbig@Informatik.BA-Stuttgart.DE>
To:        bde@FreeBSD.ORG (Bruce Evans)
Cc:        cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG
Subject:   Re: cvs commit: src/usr.sbin/chown chown.c
Message-ID:  <199805030948.LAA01172@rvc1.informatik.ba-stuttgart.de>
In-Reply-To: <199805030417.VAA21679@freefall.freebsd.org> from Bruce Evans at "May 2, 98 09:17:53 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> bde         1998/05/02 21:17:53 PDT
> 
>   Modified files:
>     usr.sbin/chown       chown.c 
>   Log:
>   Backed out previous commit.  chown(8) doesn't follow symlinks by
>   default, at least in BSD.  This used to be automatic, because chown(2)
>   didn't follow symlinks.  When chown(2) was changed to follow symlinks
>   in BSD4.4, chown(8) was changed to not follow symlinks by default.
>   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).

I suggest to implement the 4.4BSD behaviour as outlined in symlink(7),
and documented in the man page of chown(8).

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

>   Unfixed problems:
>   1. When lchown(2) was implemented, chown(8) wasn't changed to implement
>      the historical behaviour of changing ownership of symlinks.  I'm not
>      sure if it should have been.  The -HLP options give more complete
>      control, but they unfortunately don't apply unless the -R option is
>      specified (a problem shared with other commands, e.g., cp; I guess
>      we're supposed to use -R even for non-recursive traversals).

The -h option gives complete control in the nonrecursive case, and
the -R[HL] options in the recursive case, if implemented as outlined above.

>   2. If we implement the historical behaviour, then -h would become a no-op
>      and should be left undocumented.

But then at least symlink(7) should be changed to reflect this.

>   3. The man page suggests that without option -h, all symlinks (to files
>      specified in the command line?) are followed.  It's not clear what
>      "the file" is.  These bugs were introduced when -h was documented.

``the file'' is the one given on the command line.

>   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.

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).

Wolfgang

>   Revision  Changes    Path
>   1.12      +2 -1      src/usr.sbin/chown/chown.c

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805030948.LAA01172>