I'm not an expert on this type of thing, but a couple things jump out at me right away.

I assume the reason he didn't hash the password was so he could use it to decrypt the encrypted information. However, since the user is (obviously) inputting the password, he could just store that in a session variable for decryption, which would still allow him to store the hash of the password for authentication purposes. You would then run the risk of the key being stolen via XSS, but I think that would a much better configuration. Plus, if XSS is present, that could likely be leveraged to gain the same access even if the key wasn't present. If you didn't want to store the key in plain text in the session, you could use the user's IP to encrypt/decrypt it during processing, since that should be static throughout the session. See, I'm just brainstorming here

Absolutely do not assume something is safe because it is stored in a script that is not generally output in standard HTML. If there are command injection or file include vulnerabilities, those would likely allow the contents of the files to be displayed. I'm pretty sure I've also seen broken PHP configurations just dump the file instead of processing it; a future configuration change could be disastrous. Also, do not make the assumption that such a compromise would be isolated to a single user either. If they can list directory contents, cat files, etc.; it would likely be trivial do that for all users/directories/files.

What kind of script?  If the script is a client-side script (i.e. javascript), then any user can read it even if it's sourced in and not viewable using "right-click and View Source".  If the user/attacker has trouble reading it in the browser, he can just use Wireshark to read it as it comes across the wire.  This is a god-awful-never-even-think-about-it idea.

If the script is stored and executed server-side, it's trickier but still possible to recover the password.   In this case, the attacker needs some sort of disclosure vulnerability.  This is better, but not good.

The secure thing would be to not have a global master password.  Then, users are responsible for their own data.  If they forget their own master password, they lose their information and have to start over.  The site could reset their master password, but the saved passwords for other sites would be lost.  This is probably the best choice.

I don't know of a safe way to implement the global master password.  If the password is stored on the server and an attacker gets unfiltered access to the server, the attacker has the password.  If the password is sent to the client, everyone has the password.  Ditch the global master.

I misunderstood; I thought he had a master password for the entire site in addition to each user's master. 

I wondered why you were talking about XSS, but it makes more sense now.  If the user's password/hash is stored in state then XSS could potentially recover it for an attacker.

In the case of per-user master passwords, they should not be stored in the database and the hash shouldn't either so it sounds like he got that right.  The password/hash can be kept in state for the user's session.  I don't know how you mean that he's storing it in the script.  Do you mean it's put into the dynamically generated homepage of the user?  If so, it's being sent to the user in the clear and would be vulnerable to XSS attacks (if any exist on the site). 

Rather than pass it back to the user in plaintext, the site could encrypt it with a per-session key and hand it back to the user that way.  The server could generate a new key for each session and use it to encrypt/decrypt the user's password hash during that session without ever storing it in the database.   This limits the amount of time that the server ever has the hash accessible to itself and would be especially helpful for inactive sessions.   XSS would not work because the user would only have the encrypted hash at any given time and server-side attacks would be limited because the server would only know how to decrypt the encrypted hash and would only have a few decrypted in memory at any given time.

Just to clarify, I'm assuming that he hashes the password with MD5, SHA, or a construction like PBKDF2.  That hash would be used as the key to encrypt/decrypt the user's information in the database.  Call this value 'hash(password)'.  Your friend currently stores the plaintext password in a script for the user's home page, but I'm not clear on how exactly he is doing that.  I'm suggesting that he generate a session key and encrypt the hash and pass that back to the user, call it 'encrypt(hash(password))'. 

Does this make sense?

What does the master password do exactly?

I have written an app before that used a similar setup but the master password was more of the value of an  encryption key that was stored (hashed) in a configuration file, with the keys residing at the OS level.

Are the other sites similar sites to this or common social networking sites and this is a portal to those? Just curious as to the goal.