Standards Update (3 of 4): NBS FIPS

Shane P. McCarron ahby at
Thu Jan 28 13:26:51 AEST 1988

From: ahby at (Shane P. McCarron)

In article <116 at longway.TIC.COM> guy at (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 at 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

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
Shane P. McCarron			UUCP: ahby at
Systems Analyst				ATT: +1 612 224-9239

Volume-Number: Volume 13, Number 10

More information about the Comp.std.unix mailing list