🚀 go-pugleaf

From: ahby@bungia.bungia.mn.org (Shane P. McCarron)


In article <116@longway.TIC.COM> guy@sun.com (Guy Harris) writes:
>From: uunet!Sun.COM!guy (Guy Harris)
>
>This may want to be forwarded to Shane, rather than posted; unfortunately,
>I don't remember his email address.
>
>[ He's ahby@bungia.mn.org or uunet!rutgers!umn-cs!bungia!ahby,
>but this looks like a useful correction of a technical detail
>(one I missed on review) that should be posted. -mod ]
>
>        - Only the super-user shall be allowed to link or
>          unlink directories (2.10.4, lines 938 - 939).
>
>          Another useful option.  A portable application may
>          need to know whether it requires "approprite
>          privileges" to move directories around.
>
>No portable application needs "appropriate privileges" to move directories
>around; it can use "rename()".  The correct way to move anything under a POSIX
>implementation is to use "rename()", not "link()" and "unlink()".

Mea culpa, mea culpa :-) 

Of course Guy is right.  No portable application may ever require
appropriate privilege and still be portable.  Especially since that
privilege will be very hard to define (or come by) in a trusted
environment.

What I was trying to imply was that if appropriate privilege is
required to link() and unlink() directories, and an application needs
that ability for some unforseeable reason, then it should probably
fail to compile on that instance of that implementation.  

The rename() call is sufficient for changing the name of a directory, 
but is hardly sufficient for creating multiple links to the same 
directory, or some other arcane use.  It occurs to me that this may
only be possible today using symbolic links, but you get the idea.  My
advice to application developers is to not even try to write code that
requires anything that could be percieved as an option under POSIX.
If you stick to the minimal set, you will be safe.  Your application
won't do anything, but... :-)

Thanks for pointing out that rather glaring error.  I must be getting
senile.
-- 
Shane P. McCarron			UUCP: ahby@bungia.mn.org
Systems Analyst				ATT: +1 612 224-9239

Volume-Number: Volume 13, Number 10