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

[Peter Avalos]

On Mon, Nov 10, 2008 at 05:04:33PM -0800, Matthew Dillon wrote:
> 
> :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.
> 

Ok, I think I see what's going on here.  Our utilities don't actually do
what symlink(7) says.  It looks like FreeBSD changed this behavior in
2001 and NetBSD in 2002.

Additionally, from IEEE Std 1003.1-2001:
If a symbolic link is encountered during pathname resolution, the
behavior shall depend on whether the pathname component is at the end of
the pathname and on the function being performed. If all of the
following are true, then pathname resolution is complete:

   1.  This is the last pathname component of the pathname.
   2.  The pathname has no trailing slash.
   3.  The function is required to act on the symbolic link itself, or
   certain arguments direct that the function act on the symbolic link
   itself.

In all other cases, the system shall prefix the remaining pathname, if
any, with the contents of the symbolic link.
______________


I see what you're saying WRT your examples, and I'm not saying we have
to be standards nazis, but in this case I think we should follow the
standard, especially since other OSs have done the same.


--Peter
Attachment:
pgp00001.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/commits/attachments/20081110/d4b611da/attachment-0020.obj>