Hard link as an alternate to symlink/copy

[Gary Mort]

Overall, modman is a nice structure for deploying components.

I personally do not like allowing symlink - their a security risk*1

Copy is rather limited in that it cannot handle maintenance.

Hard links were pretty much designed for this situation. So I'm somewhat curious on why symlinks ended up being used quite so much instead of using hard links? Was this a deliberate decision?

*1: If you assume that the web server is going to be allowed to follow symlinks, then there is no issue. However, since the default behaviour is not to follow symlinks - it can be highly convenient to use symlinks to segregate data. For example, when trying to break people of the habit of making an sql data dumb or a tar archive all files inside the html folder - I generally
-- create a couple subdirectories, [backuppath]/data/badhabits and [backuppath]/data/badhabitsdiehard
-- symlink the badhabits subdirectory to [webroot]/backups and whatever directories I find they have been using inside the webrootare deleted and symlinked to [backuppath]/data/badhabitsdiehard
-- make sure Options -FollowSymLinks is in the htaccess file for the root directory
-- instruct them to use the [backuppath]/data folder

Most of the time, the lecture doesn't do any good and data dumps and backup files continue to be stuck inside the webroot. However:
-- Since the directory is not really there, the files cannot be accessed/downloaded by a web browser
-- For my own amusement, I can see how many dumps are being placed by habit[they end up in badhabitsdiehard] and how many due to ignorance[they end up in badhabits]

It wasn't until I ran across my first site using modman that this simple security mechanism broke the site.

And no, I do not feel "just don't save sensitive data to the webroot" is an acceptable answer. That answer is acceptable only if you are in complete charge of the system and thus are the only one[or company] that is able to create these files. In the real world, where the client pays for hosting and has full write access - it is sheer laziness not to take an extra 10 minutes to try to keep them from exposing sensitive data.

[Colin Mollenhour]

Hi Gary,

Yes, the decision was quite deliberate. Symlinks can easily be distinguished from regular files whereas hardlinks are the same as regular files. That is, once a file is hardlinked there is no simple way to tell which was the original or where it originated from. For example, if you delete a modman module now or check out a new branch that rearranges a lot of files you can run modman clean and the broken symlinks will be cleaned up. With hardlinks this would be extremely difficult. There is the --copy option but cleaning up orphaned files is an exercise left up to the user.

I see that since you have been using FollowSymLinks as a security feature it conflicts with the way modman is used. I don't know the details of your system but perhaps you could write a script which makes sure that a .htaccess file with Options +FollowSymLinks is created in every directory that contains symlinks created by modman. That is, the parent directory of every target (right side) listed in every modman file. Note that this option only affects Apache so once the dynamic script starts execution most languages will always follow symlinks as this is just the way the OS reads files.

[Gary Mort]

Thanks... Modman is a convenient, well thought out, platform neutral way of defining how to map files/directories from a source directory to a website[looking it over, there is nothing magento specific - you could use the same structure to a Joomla extension, or a Wordpress plugin].

As for the cleanup process... it requires a couple extra steps but in general is easier then with copies. You just need a couple extra directories:
" For example, if you delete a modman module now or check out a new branch that rearranges a lot of files you can run modman clean and the broken symlinks will be cleaned up. With hardlinks this would be extremely difficult."

Assuming:
app/code/community/myname/mymodule/etc/config.xml
and the repository is
.modman/mymodule/etc/config.xml

For deployment add the following:
.modman/.original/mymodule/etc/config.xml
.modman/.deployed/app/code/community/myname/mymodule/etc/config.xml

Now it is easy. Simple inode comparisons can now handle all file changes/deletions. You do lose the ability to clean up directory structures - but then modman doesn't really do that cleanly anyway.

Since the heavy lifting of establishing a common definition file has already been done by modman, I can just add some extra functionality for myself. Knowing there is no interest from others in using hard links, I don't need to worry about fitting it into modman itself.

[Colin Mollenhour]

That's an interesting idea, though I still am not sure I'd call it easy. The devil is always in the details. :)

Good luck and feel free to submit a PR if you decide to make it an option to the original script.