On Tuesday 29 September 2009 1:22:56 pm you wrote: > On Tue, Sep 29, 2009 at 3:09 PM, Ricardo Cantu <rica...@smartcsc.com> wrote: > > On Tuesday 29 September 2009 12:14:51 pm you wrote: > > > On Tue, Sep 29, 2009 at 12:51 PM, Ricardo Cantu <rica...@smartcsc.com > > > > > >wrote: > > > > > Ricardo Cantu wrote: > > > > > > > > > > That's the problem with mod_fcgid right now with out the patch. > > > > > argv[0] is different but mod_fcgid is not considering it different. > > > > It > > > > > > > is lumping together by inode only and not paying attention to > > > > basename > > > > > > (argv[0]). > > > > > > > > > Which can be different when using symbolic links. > > > > > The patch is so it can properly respect your statement. > > > > > > > > > > Ah ha - I misread your statement. > > > > > > > > So, is the patch acceptable? > > > > > > Doesn't the patch require the symlink to reside in the same directory > > > as the actual executable in order to be effective? > > > > No > > got it > > > > Wouldn't tracking the devno/inode of the link itself (apr_lstat() > > > instead of apr_stat()) handle the issue more cleanly? It wouldn't work > > > for hard links, but it should be a sufficient capability. > > > > > > As suggested in an earlier mail, why not always fully respect the > > > symlink as distinct from other filesystem paths that resolve to the > > > same executable code? > > > > Thought about all the possible scenarios and as far as i can see > > respecting basename (argv[0] ) is the one that handles all of them. For > > instance using apr_lstat would interfere with someone who likes to put > > all executables in one > > directory then link them to what ever other directory they need it in. > > > > So > > /usr/bin/program1 > > ln -s /usr/bin/program1 /var/www/virtual1/bin/program1 > > ln -s /usr/bin/program1 /var/www/virtual2/bin/program1 > > > > Needs to consider all program1's the same. > > note that programs in different vhosts are in different classes for other > reasons > > what about this example? > > /www/foo.example.com/catalog/index.fcgi > /www/foo.example.com/survey/index.fcgi > > In general, two commands with the same basename probably aren't the same > application.
The patch does not disable the inode/devnode check. So the previous example would work as expected. The index.fcgi's are different. > > > On the other hand: > > > > /usr/bin/program1 > > ln -s /usr/bin/program1 /var/www/virtual1/bin/program2 > > ln -s /usr/bin/program1 /var/www/virtual2/bin/program3 > > > > Needs to consider program1,program2,program3 different. > > > > sure >
