>>suEXEC security model will not allow target programs that are
>>symbolic links to be run
>
>Well, I don't think this is a security issue - I think it is a bug.
>I haven't investigated thoroughly yet but it doesn't make sense to me
>that symbolic links should be allowed for intermediate directories
>while linking to the actual file to be executed is not allowed.
>Perhaps links are not allowed anywhere along the whole path, but
>why would this be more secure?
>
>Apache has a separate restriction on the use of symbolic links that should
>be sufficient, where that restriction is needed at all.
>
>One workaround is to use the --copy option on setup.pl.
>But 1.9.9 has a bug regarding copying to the Admin directory - it
>doesn't do it.
You make a good point when you question the rationale for suEXEC refusing
to execute a program if you try to invoke it via a symbolic link. Maybe
suEXEC refuses because it does not know if the location of the program is
within the allowed file space (i.e. user document root.) It might be hard
for suEXEC to track this down if the file you pass to it is a sym link to
another sym link to another sym link (etc., etc.) before finally getting
to the program to be executed. So, it decides instead to just reject all
sym-linked programs instead.
I just got a copy of cgiwrap (version 3.6.3) and it also refuses
to execute target programs that are sym links (unless you indicate
--without-check-symlink when you configure the program.)
>>This made me wonder just why symbolic links are used so much in
>>HyperNews. Why not use hard links for files like edit-article.pl above?
>
>Hard links might work just as well while maybe solving the problem
>of use with suEXEC. I'll have to experiment.
I made a copy of the linkIt() subroutine in setup.pl then modified it to
create hard links instead of symbolic links. I renamed the original
linkIt() subroutine to symlinkIt() then modified the setupScriptDirs()
subroutine to use it to create sym links to the directories.
Everything seemed to work OK and suEXEC did not complain.
I did not experience any problem regarding the Admin directory.
The immediate advantage I see with using suEXEC instead of cgiwrap is that
apache will process all the .htaccess access control files before invoking
suEXEC. So, you do not need to create all the cgiwrap links in the
HyperNews directories that you would need with cgiwrap.
>>Or, why not refer to the program directly instead
>>of using any sort of link?
>Links are used, symbolic or hard, because we use the server's
>directory based access control mechanism. Since the same scripts are used
>whether under access control or not, we just link from the appropriate
>directories. Links are also used to get access to the hnrc file and
>the library script files. There are other ways this could be done,
>but it works well enough for now.
Well, I cannot argue with your last sentence!
Also, I understand that some HyperNews scripts might need to be called with
access control while other times they need access control. So, this means
that you need at least one place to access the scripts without server
access control (like HyperNews/) and another that does have access control
(like HyperNews/SECURED/)
But, there are also the following places where the scripts (or links to scripts) are located:
HyperNews/.scripts/
HyperNews/.scripts/Admin/
HyperNews/.scripts/SECURED/
HyperNews/.scripts/.scripts/
HyperNews/.scripts/.scripts/Admin/
HyperNews/.scripts/.scripts/SECURED/
... etc.
HyperNews/Admin/
HyperNews/Admin/.scripts/
... etc.
HyperNews/Admin/Admin/
... etc.
HyperNews/SECURED/Admin/
... etc.
HyperNews/SECURED/.scripts/
... etc.
It's hard for me to keep track of all of these directories and scripts
(some of them linked to themselves.) You might consider using Occam's
razor to trim off a few script directories in HyperNews 1.9.9+.
But, as you said, everything works now, which is what matters! Thanks for
an interesing program.
Doug
| 
Changed setup.pl to use hard links; seems to work 
Design question: why so many symbolic links?
(Douglas Yatcilla)
Links are needed for sharing
(Daniel LaLiberte)
Error-log
by rguyer@dual-tech.com, 1999, Mar 20
