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
> > 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. 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.
