cvs commit: src/usr.bin/chflags chflags.c

[Matthew Dillon]

:Well I expected chflags's behavior to be like chown -- that is, if I
:chflags a symlink, I expect it to do the operation on the underlying
:file, just like chown would do.  To operate on the actual symlink, I'm
:going to add a -h option to chflags which will use the new lchflags
:syscall.
:
:I don't think my assumption or expectations are out of line.  Otherwise,
:there's no way to do any chflags ops through a symlink.
:
:--Peter

    Here's the problem.  

	userA: ln -s /root/.cshrc .cshrc
	root: cd ~userA; chown userA .cshrc

    In otherwords, when the behavior operates like this, the chances of
    a common mistake creating a very serious issue in the system becomes
    very high.

    If you have a softlink to a directory and specify it on the command
    line you wind up in even more trouble.

    In another example, having the operation work differently for recursive
    operations verses non-recursive operations is very bad.  Clearly this
    cannot be the default (and it isn't) for recursive operations or you
    can wind up destroying the permissions or ownership of your entire
    system if someone happens to softlink /.   But having the behavior work
    differently whether -R is specified or not is just not a good idea.
    Thus it cannot run through the softlink for either operation.

    It is very, very easy for a system administrator to shoot himself in
    the foot if these commands operate through softlinks by default.
    I really do not want any of these programs going through the symlink
    by default, particularly if we have the tools to actually control
    the ownership, modes, and flags of the link itself.

						-Matt