[2129] in WWW Security List Archive
Re: Protected Page...
daemon@ATHENA.MIT.EDU (Tom van Peer)
Tue May 21 07:29:01 1996
Date: Tue, 21 May 1996 11:03:06 +0200
To: www-security@ns2.rutgers.edu
From: tommy@knoware.nl (Tom van Peer)
Errors-To: owner-www-security@ns2.rutgers.edu
At 21:26 13-05-1996, Jeremey Barrett wrote:
>On Mon, 13 May 1996, Dana Hudes wrote:
>
>> Directories do chew up disk space. It is not just the kbytes but
>> i-nodes (on unix) or FAT entries (on DOS). For small server this is fine
>> if you only have a few documents to server up. But for a big server with
>> undreds of documents you are making life more difficult. In addition,
>> many graphics are common to all or many pages so you keep them in a
>> /icons directory or something .
>>
>> Also consider that many file systems sw will cache directories (at least
>> the TOC). I encourage grouping file together in a directory if they are
>> related to each other logically. Merely being by the same author is not
>> sufficient of course, and one certainly can and should use directory
>> tress that match the logical structure of the information you are serving.
>> Also remember when nesting your directories that there are definite
>> limits on the length of a path name on many machines (and do you really
>> want a 32-deep path name?).
>>
>
>A workaround for this might be symbolic links. In general, they
>consume less resources than a real i-node... on some systems they are
>merely an entry in the i-node pointed to by the link. You can use
>the server config files to map URL requests to wherever, and to configure
>access on each symlink separately without sucking up i-nodes with
>a bunch of directories.
If not used properly symbolic links are the second best resource consumer.
Remember that a symbolic link is just a file (directory entry, i-node,
data) which contains the name of the file it is a link to. This means that
your OS has to open that file, read the name and then go out to open the
other file with all the overhead involved. An ordinary hard link gives you
direct access to the original file because the i-node of the link points to
the original data and not to a file containing a name.
Does anyone care to elaborate on the security aspects of symbolic vs. hard
links, especially in chroot() environments ? This is after all a WWW
security list and not a basic Unix training course ;-)
----
tommy@knoware.nl
Tom van Peer
Hartingstraat 171
3511 HV Utrecht
THE NETHERLANDS
