Logical location for a webapp


  • BINNED

    I'm racking my brain around this so I want to get some more opinions.

    I have a webapp written in PHP, running on Apache in a virtual host. The app has to be able to access some files on the filesystem; specifically recorded calls, voicemails and faxes (stored as a PDF) which are all handled by Asterisk PBX software. These files should also be accessible through a Samba share if a client requests it.

    So now I'm trying to decide on a location. So far, following the Debian's standard config, my app lived in /var/www/app. Asterisk stores recordings and voicemails to /var/spool/asterisk/* by default. So far, I solved the access problem by symlinking the appropriate directories into /var/www/app/*, but creating a Samba share there seems... weird to me.

    I was thinking about /usr/share/ and /opt but I'm not that happy with them much either. Another option I toyed with is creating a new user and placing everything in /home/appname/, and then just translate the absolute paths Asterisk gives me to relative ones. So pretty much something like:

    • app lives in /home/appname/public_html
    • call recordings live in /home/appname/recordings
    • voicemails live in /home/appname/voicemail
    • faxes live in /home/appname/fax

    Note that I have a complete control over the system, so I can do pretty much everything. My main concern is the Samba share tbh. I really don't want to have a shared directory in a location that could potentially prove to be a security risk for any reason.



  • I usually put shared data somewhere under /pub. I don't like using /home for some reason.



  • I like the /home/appname approach. I'm using it for pretty much all my current projects. Everything is owned by the appname user, which is not a sudoer. So even if someone breaks in using your app's process, they aren't getting root access.

    Another thing I like to do is add export PATH="/home/appname/local/bin;$PATH" into the local .bashrc and then install all the apps my project uses under /home/appname/local/usr. This protects you from break ins even further, and also allows you to easily manage multiple versions of dependencies on per project basis.


  • BINNED

    @cartman82 said:

    Another thing I like to do is add export PATH="/home/appname/local/bin;$PATH" into the local .bashrc and then install all the apps my project uses under /home/appname/local/usr

    I like this. Even more as I do have one binary that has to run (monitoring service). Putting it in /usr/bin or /usr/sbin shouldn't cause any problems, but still, I could just plop it into /home as well and have everything there.

    I think @ender's idea is decent as well, but I like the simplicity of "just make everything owned by an unprivileged user and be done with it". Which should either Just Work™ or I can chmod g+s the folders if/when needed.



  • Exposing direct access to those files is likely extremely bad. You should probably use a local service to ensure you're only ever requesting copies of the data instead of the source data as that type of information is usually highly regulated with frequent compliance change requirements which are always emergency to implement.


  • BINNED

    @Matches said:

    Exposing direct access to those files is likely extremely bad. You should probably use a local service to ensure you're only ever requesting copies of the data instead of the source data as that type of information is usually highly regulated with frequent compliance change requirements which are always emergency to implement.

    Fair point. I actually had a long talk about allowing deletion using the web interface recently (I was against it, of course).

    Copies are, fortunately, easy to make. Of course, in the end the machine will be in client's possession and data could be nuked if someone put their mind to it.

    That's also a fair point there: maybe I should keep the files in the default /var/spool/ , make copies in /home and encrypt the /var LVM volume. Still vulnerable to logging in in single mode but nothing is fullproof...


    Filed under: Tinfoil hat mode



  • Nuking the data might be exactly what is required. If you're in the states, there are something like 13 states which require dual consent in order to record calls, if you don't have it, you must delete the recording. In a state like NY you are required to record the call and retain it. In the other states you can record without notification.

    Depending on what you're doing as a business, and why you're recording, you can be subject to enormous amounts of rules ranging from 'we require retention based on areacode and phone prefix (NPA/NXX) to 'We require retention based on mailing zip code' to 'We require retention based on where the person lives' to 'We allow an opt in, opt out and require retention based on < some identifying piece of information, such as username, account id, etc>


  • BINNED

    No such law here AFAIK, but I'll have people more skilled at reading laws check that out. From what I gathered you're required to notify anyone calling about recording (or possibility of thereof if it's a manual action) but that's it.

    If needed I'll add a nuke option somewhere, not sure how and where yet but I'll carpet bomb that bridge when I get to it.



  • Two thoughts:

    I usually make a srv directory in the root directory. It is "meant" to hold data that will be "served". The idea being that you shouldn't put anything in there unless you're willing to serve it out.

    Also, consider using reversed fully qualified domain name notation, whether you do it in /home or /srv.



  • @Captain said:

    Also, consider using reversed fully qualified domain name notation, whether you do it in /home or /srv.

    I normally use /pub/web/domain for webpages and /pub/ftp/whatever for FTP-only access (and on fileservers, /pub/samba/share). For webapps, the files are owned by root, except for files/directories that have to be writeable by the webapp.


  • Discourse touched me in a no-no place

    Sounds like a poor man's chroot jail...



  • Unlike chroot, it allows you to keep using shared apps / environment for majority of things and only localize the stuff you need for the current app.


  • BINNED

    @Onyx said:

    No such law here AFAIK, but I'll have people more skilled at reading laws check that out.

    Good choice! In my state (here in the good ole USA) if you're a business you are required to do the "this call may be recorded..." shtick, no dual consent required ( IIRC ). If you're a private citizen, well, my Asterisk home install does recordings if I press *# during the call, and I don't need to tell you squat. I also have an "Extreme Prejudice" list wherein certain obnoxious repeat call offenders get auto answered with a rendition of "Modem Muzak"...


  • BINNED

    @M_Adams said:

    In my state (here in the good ole USA) if you're a business you are required to do the "this call may be recorded..." shtick, no dual consent required ( IIRC ).

    Seems to be the case here as well from what I was told.

    @M_Adams said:

    If you're a private citizen, well, my Asterisk home install does recordings if I press *# during the call, and I don't need to tell you squat.

    Yeah, I'd like a home install as well, but getting a SIP trunk as a private citizen seems to be next to impossible, and I really don't feel like dealing with analog bullshit.

    As for one touch recording or any kind of recording done by private citizens, yeah, I don't see how you would even enforce that. Mobile phones could record conversations ages ago anyway.


  • BINNED

    @Onyx said:

    I'd like a home install as well, but getting a SIP trunk as a private citizen

    Not required...


  • BINNED

    @M_Adams said:

    Not required...

    As I said, I know, but my unwillingness to fuck around with extra hardware is greater than my need for a home PBX. I'm a lazy bastard 😛

    Also, note that I rarely even use the phone, my main use for it would be, as you mentioned yourself, screening out the jerks without having to go over and read the caller ID myself. So, meh.



  • A month later, and I've got my own setup going with

    /etc/nginx for the server (with /sites-enabled for active sites)
    /wwwjail/domain.name for web locations (/domain.name may be a local page, VM, remote mount, etc)
    /etc/mono-fastcgi (which I might actually decomm, since i have a physical windows server and it doesn't really make sense to have mono installed.)

    But I also don't respect linux normal file structure that much, so there's that.


Log in to reply