How to avoid using sudo when working in /var/www?












166















I want to stop having to use sudo everytime I work in /var/www. How can I do that? I simply want to put all of my sites into this directory and work with them without too much pain.










share|improve this question




















  • 3





    Are you using apache?

    – Rinzwind
    Jun 1 '11 at 5:29






  • 1





    After reading here, this can also help in the permission part: askubuntu.com/questions/20105/…

    – Luis Alvarado
    Jun 1 '11 at 13:31






  • 2





    Another way to get safety is to continue to use sudo -u www-data but restrict yourself in the sudoers file to only be able to sudo www-data (and not sudo root). See serverfault.com/questions/295429/…

    – Simon Woodside
    May 31 '16 at 4:18
















166















I want to stop having to use sudo everytime I work in /var/www. How can I do that? I simply want to put all of my sites into this directory and work with them without too much pain.










share|improve this question




















  • 3





    Are you using apache?

    – Rinzwind
    Jun 1 '11 at 5:29






  • 1





    After reading here, this can also help in the permission part: askubuntu.com/questions/20105/…

    – Luis Alvarado
    Jun 1 '11 at 13:31






  • 2





    Another way to get safety is to continue to use sudo -u www-data but restrict yourself in the sudoers file to only be able to sudo www-data (and not sudo root). See serverfault.com/questions/295429/…

    – Simon Woodside
    May 31 '16 at 4:18














166












166








166


156






I want to stop having to use sudo everytime I work in /var/www. How can I do that? I simply want to put all of my sites into this directory and work with them without too much pain.










share|improve this question
















I want to stop having to use sudo everytime I work in /var/www. How can I do that? I simply want to put all of my sites into this directory and work with them without too much pain.







sudo webserver






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jun 1 '11 at 19:32









Lekensteyn

122k48268358




122k48268358










asked Jun 1 '11 at 3:43









TaylorOtwellTaylorOtwell

950376




950376








  • 3





    Are you using apache?

    – Rinzwind
    Jun 1 '11 at 5:29






  • 1





    After reading here, this can also help in the permission part: askubuntu.com/questions/20105/…

    – Luis Alvarado
    Jun 1 '11 at 13:31






  • 2





    Another way to get safety is to continue to use sudo -u www-data but restrict yourself in the sudoers file to only be able to sudo www-data (and not sudo root). See serverfault.com/questions/295429/…

    – Simon Woodside
    May 31 '16 at 4:18














  • 3





    Are you using apache?

    – Rinzwind
    Jun 1 '11 at 5:29






  • 1





    After reading here, this can also help in the permission part: askubuntu.com/questions/20105/…

    – Luis Alvarado
    Jun 1 '11 at 13:31






  • 2





    Another way to get safety is to continue to use sudo -u www-data but restrict yourself in the sudoers file to only be able to sudo www-data (and not sudo root). See serverfault.com/questions/295429/…

    – Simon Woodside
    May 31 '16 at 4:18








3




3





Are you using apache?

– Rinzwind
Jun 1 '11 at 5:29





Are you using apache?

– Rinzwind
Jun 1 '11 at 5:29




1




1





After reading here, this can also help in the permission part: askubuntu.com/questions/20105/…

– Luis Alvarado
Jun 1 '11 at 13:31





After reading here, this can also help in the permission part: askubuntu.com/questions/20105/…

– Luis Alvarado
Jun 1 '11 at 13:31




2




2





Another way to get safety is to continue to use sudo -u www-data but restrict yourself in the sudoers file to only be able to sudo www-data (and not sudo root). See serverfault.com/questions/295429/…

– Simon Woodside
May 31 '16 at 4:18





Another way to get safety is to continue to use sudo -u www-data but restrict yourself in the sudoers file to only be able to sudo www-data (and not sudo root). See serverfault.com/questions/295429/…

– Simon Woodside
May 31 '16 at 4:18










7 Answers
7






active

oldest

votes


















235














Most answers here are not written with security in mind. It's good to get a feeling that running sudo each time is not very wise. If you make a typo (for example single white space on a wrong place: sudo rm -rf / var/www/dir do not execute!), you might trash your system.



Note: Starting with Apache 2.4.7 / Ubuntu 14.04, /var/www has been moved to /var/www/html Adjust the commands in this answer accordingly.



See:




  • Where to place my local website starting with the 2.4.7 version of apache2?


  • Why has the apache2 www dir been moved to /var/www/html?


  • Changing the default document root for HTTP server



Bad ideas:





  • chmod 777 (sagarchalise) - this allows anyone with access to your system write into the directories and files and thereby allowing the intruder to execute any code under the www-data user


  • chgrp -R www-data $HOME (cob) - this allows www-data to read or write any files in the home directory. This is not keeping the Least Privilege rule in mind


  • chown -R $USER:$USER /var/www (kv1dr) - unless the world has read permissions on /var/www, the webserver running under www-data will not be able to read (serve) the files. If the file is a public-accessible plain HTML document, it might not be an issue if the world can read the file. But if the file is a PHP file containing passwords, it is.


NOTE: in the below solutions, I've granted www-data write privileges. However, /usr/share/doc/base-passwd/users-and-groups.txt.gz states:




www-data



Some web servers run as www-data. Web content should not be owned by this
user, or a compromised web server would be able to rewrite a web site. Data
written out by web servers will be owned by www-data.




Where possible, do not grant write permissions to the www-data group. www-data only needs to be able to read the files so the webserver can serve it. The only case where www-data needs write permissions is for directories storing uploads and other locations which needs to be written.



Solution 1



Add yourself to the www-data group and set the setgid bit on the /var/www directory such that all newly created files inherit this group as well.



sudo gpasswd -a "$USER" www-data


Correct previously created files (assuming you to be the only user of /var/www):



sudo chown -R "$USER":www-data /var/www
find /var/www -type f -exec chmod 0660 {} ;
sudo find /var/www -type d -exec chmod 2770 {} ;


(even safer: use 640 or 2750 and manually chmod g+w file-or-dir that needs to be writable by the webserver)



Solution 2



Create a symlink for each project to your home directory. Say your project is located at ~/projects/foo and you want to have it located at /var/www/foo, run:



sudo ln -sT ~/projects/foo /var/www/foo


If your home directory has no execute bit (descend) set for other (for security reasons), change the group of it to www-data, but set the execute bit only (no read/write). Do the same for the ~/projects folder as it may contain other projects than www. (You don't need sudo if you have previously added your user to the www-data group.)



sudo chgrp www-data ~ ~/projects
chmod 710 ~ ~/projects


Set the group to www-data on ~/projects/foo and allow the webserver to read and write to files and files+directories and descend into directories:



sudo chgrp www-data ~/projects/foo
find ~/projects/foo -type f -exec chmod 660 {} ;
find ~/projects/foo -type d -exec chmod 2770 {} ;


Even safer: use 640 and 2750 by default and manually chmod files and directories that need to be writable by the webserver user. The setgid bit should be added only if you want every newly created file in ~/projects/foo to be accessible by the group.



From now on, you can access your site at http://localhost/foo and edit your project files in ~/projects/foo.



See also




  • Permissions issue: how can Apache access files in my Home directory?

  • Reasons why /var/www should not have chmod 777






share|improve this answer


























  • What do you think about a www-session in a terminal by sudo su www-data? Combined with a differently colored prompt, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion?

    – user unknown
    Jun 1 '11 at 15:18











  • @user unknown: if you do everything in the terminal fine as you've a clear separation between user-accounts. But it's not going to work if you use a GUI program like gedit. I've never researched whether running a GUI program under an other user in the current session is safe or not, it would be an interesting question.

    – Lekensteyn
    Jun 1 '11 at 15:26






  • 1





    @imaginaryRobots: if I was going to post different solutions for every question, Askubuntu would be full of answers of three lines. I'll keep it as is unless you can convince me to split it.

    – Lekensteyn
    Jun 2 '11 at 12:32






  • 1





    @berbt setfacl -d u::rwX,g::rX /var/www has the funny effect that the default mode becomes 0750 (or 0640) even if the umask is zero. It might be a good idea if you want to avoid world-writable files, but if /var/www is already inaccessible by the world it is not needed.

    – Lekensteyn
    Feb 16 '16 at 10:38






  • 1





    Is there an issue with inverting the process in solution 1? By that I mean, /var/www/app01 has ownership app01:app01, and then the www-data user is added to the app01 group? Or will that break something?

    – Jack_Hu
    May 31 '18 at 18:07





















9














Rather than storing my web sites in /var/www I place links there to the sites which are located in my home folder. I can freely edit, or add pages to my sites. When I happy with changes I then FTP to a hosting company where my domain name links.






share|improve this answer
























  • This is a sensible idea.

    – thomasrutter
    Nov 23 '16 at 23:46



















7














If you make /var/www writeable by its group and add yourself to the group, you will not have to use sudo while still being fairly secure. Try this:



sudo adduser <username> www-data
sudo chown -R www-data:www-data /var/www
sudo chmod -R g+rw /var/www


You should then be able to edit /var/www/ files without hassle.



The first line adds you to the www-data group, the second line clears up any files with messed up ownership, and the third makes it so that all users who are members of the www-data group can read and write all files in /var/www.






share|improve this answer





















  • 2





    This is a very bad idea for security and this advice should not be followed, for reasons explained in other answers. www-data is supposed to be an unprivileged group, without write access.

    – thomasrutter
    Nov 23 '16 at 23:45





















5














Don'ts





  • Don't set file permissions to 777 (world-writable)



    This is a significant security flaw, especially if you enable server-side scripting such as PHP. Unprivileged processes should not be able to write to files that would affect the website or, in the case of server-side scripting being used, execute arbitrary code.




  • Don't add yourself as a member of the www-data group and give it write permissions



    The purpose of that group is that it is an unprivileged group that the server processes run as. They should only have read access to the website files where possible, for the same reasons as above.




  • Don't change the permissions of the Apache processes



    The Apache child processes run as the www-data user and group by default, and this should not be altered. This is just a way of giving them no write permission to the filesystem.



    In certain circumstances you want your server-side scripts to be able to write to files, in which case only those files should be made writable by www-data and care needs to be taken to ensure security.




Dos





  • Set the files to be owned by yourself



    If you are the only one, or the usual one, to modify certain files on the website, then it makes total sense just to take ownership of those files. Set their owner to <your username>.



    You don't have to modify the server permissions for this, as the server will continue to get read-only access even when the files are owned by you.




  • Choose a sensible place to house the files (using DocumentRoot)



    If /var/www doesn't make sense, you are welcome to place them elsewhere. If they are specific to your own development or testing, you could place them in your home directory. Or you can set up some directories in /srv.




  • If you want to give group write access, create a new group for the purpose



    Don't re-use a system group, because these are typically designed to have the access they currently have, and no more, for security reasons.








share|improve this answer

































    5














    It's this simple. You neither need to enable apache 'UserDir' (not recommended) nor messing up with 'www-data' groups (apache group in case on Fedora)



    Just create your project directory inside /var/www/html



    cd /var/www/html
    sudo mkdir my_project


    Then just chown the project directory to your user.



    sudo chown your_username my_project


    Now you can start working on your project folder as a regular user with any editor, IDE of your choice. No more sudos : )






    share|improve this answer





















    • 1





      +1 That's what I do: change ownership not of /var/www itself, but of subdirectories.

      – fkraiem
      Oct 20 '16 at 15:33





















    1














    chmod in /var on www to allow the owner access, and chown to make sure you own it. Probably a stupid idea, but it would definitely work.






    share|improve this answer



















    • 1





      Not a stupid idea, it's a sensible idea security-wise. Note: You don't need to (and shouldn't) change the permissions of /var, just /var/www and/or its contents.

      – thomasrutter
      Nov 23 '16 at 23:43





















    1














    You could start a www-session in a terminal by



    sudo su www-data


    Combined with a differently colored prompt*, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm (and editor and such) on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion.



    *) For a differently colored prompt with a differnt character, create a file /etc/prompt like this:



    # PROMPTING
    # When executing interactively, bash displays the primary prompt PS1 when it is ready to read a command, and the sec-
    # ondary prompt PS2 when it needs more input to complete a command. Bash allows these prompt strings to be customized
    # by inserting a number of backslash-escaped special characters that are decoded as follows:
    # a an ASCII bell character (07)
    # d the date in "Weekday Month Date" format (e.g., "Tue May 26")
    # D{format}
    # the format is passed to strftime(3) and the result is inserted into the prompt string; an empty format
    # results in a locale-specific time representation. The braces are required
    # e an ASCII escape character (033)
    # h the hostname up to the first `.'
    # H the hostname
    # j the number of jobs currently managed by the shell
    # l the basename of the shell's terminal device name
    # n newline
    # r carriage return
    # s the name of the shell, the basename of $0 (the portion following the final slash)
    # t the current time in 24-hour HH:MM:SS format
    # T the current time in 12-hour HH:MM:SS format
    # @ the current time in 12-hour am/pm format
    # A the current time in 24-hour HH:MM format
    # u the username of the current user
    # v the version of bash (e.g., 2.00)
    # V the release of bash, version + patchelvel (e.g., 2.00.0)
    # w the current working directory
    # W the basename of the current working directory
    # ! the history number of this command
    # # the command number of this command
    # $ if the effective UID is 0, a #, otherwise a $
    # nnn the character corresponding to the octal number nnn
    # \ a backslash
    # [ begin a sequence of non-printing characters, which could be used to embed a terminal control sequence
    # into the prompt
    # ] end a sequence of non-printing characters
    #
    # The command number and the history number are usually different: the history number of a command is its position in
    # the history list, which may include commands restored from the history file (see HISTORY below), while the command
    # number is the position in the sequence of commands executed during the current shell session. After the string is
    #
    # colors:
    # [...] wird benötigt, damit die shell weiß, daß hier kein printable output ist, und die Umbrüche richtig plaziert.
    #
    # ANSI COLORS
    CRE="[
    [K]"
    NORMAL="[[0;39m]"
    # RED: Failure or error message
    RED="[[1;31m]"
    # GREEN: Success message
    GREEN="[[1;32m]"
    # YELLOW: Descriptions
    YELLOW="[[1;33m]"
    # BLUE: System messages
    BLUE="[[1;34m]"
    # MAGENTA: Found devices or drivers
    MAGENTA="[[1;35m]"
    # CYAN: Questions
    CYAN="[[1;36m]"
    # BOLD WHITE: Hint
    WHITE="[[1;37m]"
    #
    # default:
    # postgres, oracle, www-data
    #
    # PS1=$BLUE"machine]->"$NORMAL\w"$BLUE ø $NORMAL"
    PS1=$BLUE"machine]:"$NORMAL\w"$BLUE > $NORMAL"
    #
    # root, stefan:
    #
    case "$UID" in
    '0')
    PS1=$RED"machine:"$NORMAL\w"$RED # $NORMAL"
    ;;
    '1000')
    PS1=$GREEN"machine:"$BLUE\w$YELLOW" > "$NORMAL
    ;;
    # default)
    # ;;
    esac


    and source it from /etc/bash.bashrc for instance.



    As additional tool to help distinction, you could always edit your files with an alias 'edit' or a symlink, which points, depending on your identity (taylor/www-data) to either gedit or mousepad, vim or pico. Or you could use different editor profiles, at least in gedit you may set your preferences to black text on white ground or white text on black ground for instance.



    I only have such a policy for working as root, so I'm not sure how good it will fit to working with www-data. Combined with ssh-sessions to differnt hosts, which have their own prompts, it didn't stop me from being sometimes wrong, but if it happens, I realize fast, what is wrong, and it happens rarely.



    note: The prompt-script is partly a copy of the manpage of bash.






    share|improve this answer
























    • This will work, and will not (if used carefully) negatively impact security, but may not be the most straightforward solution. It's a valid solution for some people though.

      – thomasrutter
      Nov 23 '16 at 23:47











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "89"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f46331%2fhow-to-avoid-using-sudo-when-working-in-var-www%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    7 Answers
    7






    active

    oldest

    votes








    7 Answers
    7






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    235














    Most answers here are not written with security in mind. It's good to get a feeling that running sudo each time is not very wise. If you make a typo (for example single white space on a wrong place: sudo rm -rf / var/www/dir do not execute!), you might trash your system.



    Note: Starting with Apache 2.4.7 / Ubuntu 14.04, /var/www has been moved to /var/www/html Adjust the commands in this answer accordingly.



    See:




    • Where to place my local website starting with the 2.4.7 version of apache2?


    • Why has the apache2 www dir been moved to /var/www/html?


    • Changing the default document root for HTTP server



    Bad ideas:





    • chmod 777 (sagarchalise) - this allows anyone with access to your system write into the directories and files and thereby allowing the intruder to execute any code under the www-data user


    • chgrp -R www-data $HOME (cob) - this allows www-data to read or write any files in the home directory. This is not keeping the Least Privilege rule in mind


    • chown -R $USER:$USER /var/www (kv1dr) - unless the world has read permissions on /var/www, the webserver running under www-data will not be able to read (serve) the files. If the file is a public-accessible plain HTML document, it might not be an issue if the world can read the file. But if the file is a PHP file containing passwords, it is.


    NOTE: in the below solutions, I've granted www-data write privileges. However, /usr/share/doc/base-passwd/users-and-groups.txt.gz states:




    www-data



    Some web servers run as www-data. Web content should not be owned by this
    user, or a compromised web server would be able to rewrite a web site. Data
    written out by web servers will be owned by www-data.




    Where possible, do not grant write permissions to the www-data group. www-data only needs to be able to read the files so the webserver can serve it. The only case where www-data needs write permissions is for directories storing uploads and other locations which needs to be written.



    Solution 1



    Add yourself to the www-data group and set the setgid bit on the /var/www directory such that all newly created files inherit this group as well.



    sudo gpasswd -a "$USER" www-data


    Correct previously created files (assuming you to be the only user of /var/www):



    sudo chown -R "$USER":www-data /var/www
    find /var/www -type f -exec chmod 0660 {} ;
    sudo find /var/www -type d -exec chmod 2770 {} ;


    (even safer: use 640 or 2750 and manually chmod g+w file-or-dir that needs to be writable by the webserver)



    Solution 2



    Create a symlink for each project to your home directory. Say your project is located at ~/projects/foo and you want to have it located at /var/www/foo, run:



    sudo ln -sT ~/projects/foo /var/www/foo


    If your home directory has no execute bit (descend) set for other (for security reasons), change the group of it to www-data, but set the execute bit only (no read/write). Do the same for the ~/projects folder as it may contain other projects than www. (You don't need sudo if you have previously added your user to the www-data group.)



    sudo chgrp www-data ~ ~/projects
    chmod 710 ~ ~/projects


    Set the group to www-data on ~/projects/foo and allow the webserver to read and write to files and files+directories and descend into directories:



    sudo chgrp www-data ~/projects/foo
    find ~/projects/foo -type f -exec chmod 660 {} ;
    find ~/projects/foo -type d -exec chmod 2770 {} ;


    Even safer: use 640 and 2750 by default and manually chmod files and directories that need to be writable by the webserver user. The setgid bit should be added only if you want every newly created file in ~/projects/foo to be accessible by the group.



    From now on, you can access your site at http://localhost/foo and edit your project files in ~/projects/foo.



    See also




    • Permissions issue: how can Apache access files in my Home directory?

    • Reasons why /var/www should not have chmod 777






    share|improve this answer


























    • What do you think about a www-session in a terminal by sudo su www-data? Combined with a differently colored prompt, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion?

      – user unknown
      Jun 1 '11 at 15:18











    • @user unknown: if you do everything in the terminal fine as you've a clear separation between user-accounts. But it's not going to work if you use a GUI program like gedit. I've never researched whether running a GUI program under an other user in the current session is safe or not, it would be an interesting question.

      – Lekensteyn
      Jun 1 '11 at 15:26






    • 1





      @imaginaryRobots: if I was going to post different solutions for every question, Askubuntu would be full of answers of three lines. I'll keep it as is unless you can convince me to split it.

      – Lekensteyn
      Jun 2 '11 at 12:32






    • 1





      @berbt setfacl -d u::rwX,g::rX /var/www has the funny effect that the default mode becomes 0750 (or 0640) even if the umask is zero. It might be a good idea if you want to avoid world-writable files, but if /var/www is already inaccessible by the world it is not needed.

      – Lekensteyn
      Feb 16 '16 at 10:38






    • 1





      Is there an issue with inverting the process in solution 1? By that I mean, /var/www/app01 has ownership app01:app01, and then the www-data user is added to the app01 group? Or will that break something?

      – Jack_Hu
      May 31 '18 at 18:07


















    235














    Most answers here are not written with security in mind. It's good to get a feeling that running sudo each time is not very wise. If you make a typo (for example single white space on a wrong place: sudo rm -rf / var/www/dir do not execute!), you might trash your system.



    Note: Starting with Apache 2.4.7 / Ubuntu 14.04, /var/www has been moved to /var/www/html Adjust the commands in this answer accordingly.



    See:




    • Where to place my local website starting with the 2.4.7 version of apache2?


    • Why has the apache2 www dir been moved to /var/www/html?


    • Changing the default document root for HTTP server



    Bad ideas:





    • chmod 777 (sagarchalise) - this allows anyone with access to your system write into the directories and files and thereby allowing the intruder to execute any code under the www-data user


    • chgrp -R www-data $HOME (cob) - this allows www-data to read or write any files in the home directory. This is not keeping the Least Privilege rule in mind


    • chown -R $USER:$USER /var/www (kv1dr) - unless the world has read permissions on /var/www, the webserver running under www-data will not be able to read (serve) the files. If the file is a public-accessible plain HTML document, it might not be an issue if the world can read the file. But if the file is a PHP file containing passwords, it is.


    NOTE: in the below solutions, I've granted www-data write privileges. However, /usr/share/doc/base-passwd/users-and-groups.txt.gz states:




    www-data



    Some web servers run as www-data. Web content should not be owned by this
    user, or a compromised web server would be able to rewrite a web site. Data
    written out by web servers will be owned by www-data.




    Where possible, do not grant write permissions to the www-data group. www-data only needs to be able to read the files so the webserver can serve it. The only case where www-data needs write permissions is for directories storing uploads and other locations which needs to be written.



    Solution 1



    Add yourself to the www-data group and set the setgid bit on the /var/www directory such that all newly created files inherit this group as well.



    sudo gpasswd -a "$USER" www-data


    Correct previously created files (assuming you to be the only user of /var/www):



    sudo chown -R "$USER":www-data /var/www
    find /var/www -type f -exec chmod 0660 {} ;
    sudo find /var/www -type d -exec chmod 2770 {} ;


    (even safer: use 640 or 2750 and manually chmod g+w file-or-dir that needs to be writable by the webserver)



    Solution 2



    Create a symlink for each project to your home directory. Say your project is located at ~/projects/foo and you want to have it located at /var/www/foo, run:



    sudo ln -sT ~/projects/foo /var/www/foo


    If your home directory has no execute bit (descend) set for other (for security reasons), change the group of it to www-data, but set the execute bit only (no read/write). Do the same for the ~/projects folder as it may contain other projects than www. (You don't need sudo if you have previously added your user to the www-data group.)



    sudo chgrp www-data ~ ~/projects
    chmod 710 ~ ~/projects


    Set the group to www-data on ~/projects/foo and allow the webserver to read and write to files and files+directories and descend into directories:



    sudo chgrp www-data ~/projects/foo
    find ~/projects/foo -type f -exec chmod 660 {} ;
    find ~/projects/foo -type d -exec chmod 2770 {} ;


    Even safer: use 640 and 2750 by default and manually chmod files and directories that need to be writable by the webserver user. The setgid bit should be added only if you want every newly created file in ~/projects/foo to be accessible by the group.



    From now on, you can access your site at http://localhost/foo and edit your project files in ~/projects/foo.



    See also




    • Permissions issue: how can Apache access files in my Home directory?

    • Reasons why /var/www should not have chmod 777






    share|improve this answer


























    • What do you think about a www-session in a terminal by sudo su www-data? Combined with a differently colored prompt, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion?

      – user unknown
      Jun 1 '11 at 15:18











    • @user unknown: if you do everything in the terminal fine as you've a clear separation between user-accounts. But it's not going to work if you use a GUI program like gedit. I've never researched whether running a GUI program under an other user in the current session is safe or not, it would be an interesting question.

      – Lekensteyn
      Jun 1 '11 at 15:26






    • 1





      @imaginaryRobots: if I was going to post different solutions for every question, Askubuntu would be full of answers of three lines. I'll keep it as is unless you can convince me to split it.

      – Lekensteyn
      Jun 2 '11 at 12:32






    • 1





      @berbt setfacl -d u::rwX,g::rX /var/www has the funny effect that the default mode becomes 0750 (or 0640) even if the umask is zero. It might be a good idea if you want to avoid world-writable files, but if /var/www is already inaccessible by the world it is not needed.

      – Lekensteyn
      Feb 16 '16 at 10:38






    • 1





      Is there an issue with inverting the process in solution 1? By that I mean, /var/www/app01 has ownership app01:app01, and then the www-data user is added to the app01 group? Or will that break something?

      – Jack_Hu
      May 31 '18 at 18:07
















    235












    235








    235







    Most answers here are not written with security in mind. It's good to get a feeling that running sudo each time is not very wise. If you make a typo (for example single white space on a wrong place: sudo rm -rf / var/www/dir do not execute!), you might trash your system.



    Note: Starting with Apache 2.4.7 / Ubuntu 14.04, /var/www has been moved to /var/www/html Adjust the commands in this answer accordingly.



    See:




    • Where to place my local website starting with the 2.4.7 version of apache2?


    • Why has the apache2 www dir been moved to /var/www/html?


    • Changing the default document root for HTTP server



    Bad ideas:





    • chmod 777 (sagarchalise) - this allows anyone with access to your system write into the directories and files and thereby allowing the intruder to execute any code under the www-data user


    • chgrp -R www-data $HOME (cob) - this allows www-data to read or write any files in the home directory. This is not keeping the Least Privilege rule in mind


    • chown -R $USER:$USER /var/www (kv1dr) - unless the world has read permissions on /var/www, the webserver running under www-data will not be able to read (serve) the files. If the file is a public-accessible plain HTML document, it might not be an issue if the world can read the file. But if the file is a PHP file containing passwords, it is.


    NOTE: in the below solutions, I've granted www-data write privileges. However, /usr/share/doc/base-passwd/users-and-groups.txt.gz states:




    www-data



    Some web servers run as www-data. Web content should not be owned by this
    user, or a compromised web server would be able to rewrite a web site. Data
    written out by web servers will be owned by www-data.




    Where possible, do not grant write permissions to the www-data group. www-data only needs to be able to read the files so the webserver can serve it. The only case where www-data needs write permissions is for directories storing uploads and other locations which needs to be written.



    Solution 1



    Add yourself to the www-data group and set the setgid bit on the /var/www directory such that all newly created files inherit this group as well.



    sudo gpasswd -a "$USER" www-data


    Correct previously created files (assuming you to be the only user of /var/www):



    sudo chown -R "$USER":www-data /var/www
    find /var/www -type f -exec chmod 0660 {} ;
    sudo find /var/www -type d -exec chmod 2770 {} ;


    (even safer: use 640 or 2750 and manually chmod g+w file-or-dir that needs to be writable by the webserver)



    Solution 2



    Create a symlink for each project to your home directory. Say your project is located at ~/projects/foo and you want to have it located at /var/www/foo, run:



    sudo ln -sT ~/projects/foo /var/www/foo


    If your home directory has no execute bit (descend) set for other (for security reasons), change the group of it to www-data, but set the execute bit only (no read/write). Do the same for the ~/projects folder as it may contain other projects than www. (You don't need sudo if you have previously added your user to the www-data group.)



    sudo chgrp www-data ~ ~/projects
    chmod 710 ~ ~/projects


    Set the group to www-data on ~/projects/foo and allow the webserver to read and write to files and files+directories and descend into directories:



    sudo chgrp www-data ~/projects/foo
    find ~/projects/foo -type f -exec chmod 660 {} ;
    find ~/projects/foo -type d -exec chmod 2770 {} ;


    Even safer: use 640 and 2750 by default and manually chmod files and directories that need to be writable by the webserver user. The setgid bit should be added only if you want every newly created file in ~/projects/foo to be accessible by the group.



    From now on, you can access your site at http://localhost/foo and edit your project files in ~/projects/foo.



    See also




    • Permissions issue: how can Apache access files in my Home directory?

    • Reasons why /var/www should not have chmod 777






    share|improve this answer















    Most answers here are not written with security in mind. It's good to get a feeling that running sudo each time is not very wise. If you make a typo (for example single white space on a wrong place: sudo rm -rf / var/www/dir do not execute!), you might trash your system.



    Note: Starting with Apache 2.4.7 / Ubuntu 14.04, /var/www has been moved to /var/www/html Adjust the commands in this answer accordingly.



    See:




    • Where to place my local website starting with the 2.4.7 version of apache2?


    • Why has the apache2 www dir been moved to /var/www/html?


    • Changing the default document root for HTTP server



    Bad ideas:





    • chmod 777 (sagarchalise) - this allows anyone with access to your system write into the directories and files and thereby allowing the intruder to execute any code under the www-data user


    • chgrp -R www-data $HOME (cob) - this allows www-data to read or write any files in the home directory. This is not keeping the Least Privilege rule in mind


    • chown -R $USER:$USER /var/www (kv1dr) - unless the world has read permissions on /var/www, the webserver running under www-data will not be able to read (serve) the files. If the file is a public-accessible plain HTML document, it might not be an issue if the world can read the file. But if the file is a PHP file containing passwords, it is.


    NOTE: in the below solutions, I've granted www-data write privileges. However, /usr/share/doc/base-passwd/users-and-groups.txt.gz states:




    www-data



    Some web servers run as www-data. Web content should not be owned by this
    user, or a compromised web server would be able to rewrite a web site. Data
    written out by web servers will be owned by www-data.




    Where possible, do not grant write permissions to the www-data group. www-data only needs to be able to read the files so the webserver can serve it. The only case where www-data needs write permissions is for directories storing uploads and other locations which needs to be written.



    Solution 1



    Add yourself to the www-data group and set the setgid bit on the /var/www directory such that all newly created files inherit this group as well.



    sudo gpasswd -a "$USER" www-data


    Correct previously created files (assuming you to be the only user of /var/www):



    sudo chown -R "$USER":www-data /var/www
    find /var/www -type f -exec chmod 0660 {} ;
    sudo find /var/www -type d -exec chmod 2770 {} ;


    (even safer: use 640 or 2750 and manually chmod g+w file-or-dir that needs to be writable by the webserver)



    Solution 2



    Create a symlink for each project to your home directory. Say your project is located at ~/projects/foo and you want to have it located at /var/www/foo, run:



    sudo ln -sT ~/projects/foo /var/www/foo


    If your home directory has no execute bit (descend) set for other (for security reasons), change the group of it to www-data, but set the execute bit only (no read/write). Do the same for the ~/projects folder as it may contain other projects than www. (You don't need sudo if you have previously added your user to the www-data group.)



    sudo chgrp www-data ~ ~/projects
    chmod 710 ~ ~/projects


    Set the group to www-data on ~/projects/foo and allow the webserver to read and write to files and files+directories and descend into directories:



    sudo chgrp www-data ~/projects/foo
    find ~/projects/foo -type f -exec chmod 660 {} ;
    find ~/projects/foo -type d -exec chmod 2770 {} ;


    Even safer: use 640 and 2750 by default and manually chmod files and directories that need to be writable by the webserver user. The setgid bit should be added only if you want every newly created file in ~/projects/foo to be accessible by the group.



    From now on, you can access your site at http://localhost/foo and edit your project files in ~/projects/foo.



    See also




    • Permissions issue: how can Apache access files in my Home directory?

    • Reasons why /var/www should not have chmod 777







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 16 at 15:51









    pa4080

    14.1k52666




    14.1k52666










    answered Jun 1 '11 at 9:48









    LekensteynLekensteyn

    122k48268358




    122k48268358













    • What do you think about a www-session in a terminal by sudo su www-data? Combined with a differently colored prompt, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion?

      – user unknown
      Jun 1 '11 at 15:18











    • @user unknown: if you do everything in the terminal fine as you've a clear separation between user-accounts. But it's not going to work if you use a GUI program like gedit. I've never researched whether running a GUI program under an other user in the current session is safe or not, it would be an interesting question.

      – Lekensteyn
      Jun 1 '11 at 15:26






    • 1





      @imaginaryRobots: if I was going to post different solutions for every question, Askubuntu would be full of answers of three lines. I'll keep it as is unless you can convince me to split it.

      – Lekensteyn
      Jun 2 '11 at 12:32






    • 1





      @berbt setfacl -d u::rwX,g::rX /var/www has the funny effect that the default mode becomes 0750 (or 0640) even if the umask is zero. It might be a good idea if you want to avoid world-writable files, but if /var/www is already inaccessible by the world it is not needed.

      – Lekensteyn
      Feb 16 '16 at 10:38






    • 1





      Is there an issue with inverting the process in solution 1? By that I mean, /var/www/app01 has ownership app01:app01, and then the www-data user is added to the app01 group? Or will that break something?

      – Jack_Hu
      May 31 '18 at 18:07





















    • What do you think about a www-session in a terminal by sudo su www-data? Combined with a differently colored prompt, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion?

      – user unknown
      Jun 1 '11 at 15:18











    • @user unknown: if you do everything in the terminal fine as you've a clear separation between user-accounts. But it's not going to work if you use a GUI program like gedit. I've never researched whether running a GUI program under an other user in the current session is safe or not, it would be an interesting question.

      – Lekensteyn
      Jun 1 '11 at 15:26






    • 1





      @imaginaryRobots: if I was going to post different solutions for every question, Askubuntu would be full of answers of three lines. I'll keep it as is unless you can convince me to split it.

      – Lekensteyn
      Jun 2 '11 at 12:32






    • 1





      @berbt setfacl -d u::rwX,g::rX /var/www has the funny effect that the default mode becomes 0750 (or 0640) even if the umask is zero. It might be a good idea if you want to avoid world-writable files, but if /var/www is already inaccessible by the world it is not needed.

      – Lekensteyn
      Feb 16 '16 at 10:38






    • 1





      Is there an issue with inverting the process in solution 1? By that I mean, /var/www/app01 has ownership app01:app01, and then the www-data user is added to the app01 group? Or will that break something?

      – Jack_Hu
      May 31 '18 at 18:07



















    What do you think about a www-session in a terminal by sudo su www-data? Combined with a differently colored prompt, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion?

    – user unknown
    Jun 1 '11 at 15:18





    What do you think about a www-session in a terminal by sudo su www-data? Combined with a differently colored prompt, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion?

    – user unknown
    Jun 1 '11 at 15:18













    @user unknown: if you do everything in the terminal fine as you've a clear separation between user-accounts. But it's not going to work if you use a GUI program like gedit. I've never researched whether running a GUI program under an other user in the current session is safe or not, it would be an interesting question.

    – Lekensteyn
    Jun 1 '11 at 15:26





    @user unknown: if you do everything in the terminal fine as you've a clear separation between user-accounts. But it's not going to work if you use a GUI program like gedit. I've never researched whether running a GUI program under an other user in the current session is safe or not, it would be an interesting question.

    – Lekensteyn
    Jun 1 '11 at 15:26




    1




    1





    @imaginaryRobots: if I was going to post different solutions for every question, Askubuntu would be full of answers of three lines. I'll keep it as is unless you can convince me to split it.

    – Lekensteyn
    Jun 2 '11 at 12:32





    @imaginaryRobots: if I was going to post different solutions for every question, Askubuntu would be full of answers of three lines. I'll keep it as is unless you can convince me to split it.

    – Lekensteyn
    Jun 2 '11 at 12:32




    1




    1





    @berbt setfacl -d u::rwX,g::rX /var/www has the funny effect that the default mode becomes 0750 (or 0640) even if the umask is zero. It might be a good idea if you want to avoid world-writable files, but if /var/www is already inaccessible by the world it is not needed.

    – Lekensteyn
    Feb 16 '16 at 10:38





    @berbt setfacl -d u::rwX,g::rX /var/www has the funny effect that the default mode becomes 0750 (or 0640) even if the umask is zero. It might be a good idea if you want to avoid world-writable files, but if /var/www is already inaccessible by the world it is not needed.

    – Lekensteyn
    Feb 16 '16 at 10:38




    1




    1





    Is there an issue with inverting the process in solution 1? By that I mean, /var/www/app01 has ownership app01:app01, and then the www-data user is added to the app01 group? Or will that break something?

    – Jack_Hu
    May 31 '18 at 18:07







    Is there an issue with inverting the process in solution 1? By that I mean, /var/www/app01 has ownership app01:app01, and then the www-data user is added to the app01 group? Or will that break something?

    – Jack_Hu
    May 31 '18 at 18:07















    9














    Rather than storing my web sites in /var/www I place links there to the sites which are located in my home folder. I can freely edit, or add pages to my sites. When I happy with changes I then FTP to a hosting company where my domain name links.






    share|improve this answer
























    • This is a sensible idea.

      – thomasrutter
      Nov 23 '16 at 23:46
















    9














    Rather than storing my web sites in /var/www I place links there to the sites which are located in my home folder. I can freely edit, or add pages to my sites. When I happy with changes I then FTP to a hosting company where my domain name links.






    share|improve this answer
























    • This is a sensible idea.

      – thomasrutter
      Nov 23 '16 at 23:46














    9












    9








    9







    Rather than storing my web sites in /var/www I place links there to the sites which are located in my home folder. I can freely edit, or add pages to my sites. When I happy with changes I then FTP to a hosting company where my domain name links.






    share|improve this answer













    Rather than storing my web sites in /var/www I place links there to the sites which are located in my home folder. I can freely edit, or add pages to my sites. When I happy with changes I then FTP to a hosting company where my domain name links.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jun 1 '11 at 7:06









    fragosfragos

    2,66721623




    2,66721623













    • This is a sensible idea.

      – thomasrutter
      Nov 23 '16 at 23:46



















    • This is a sensible idea.

      – thomasrutter
      Nov 23 '16 at 23:46

















    This is a sensible idea.

    – thomasrutter
    Nov 23 '16 at 23:46





    This is a sensible idea.

    – thomasrutter
    Nov 23 '16 at 23:46











    7














    If you make /var/www writeable by its group and add yourself to the group, you will not have to use sudo while still being fairly secure. Try this:



    sudo adduser <username> www-data
    sudo chown -R www-data:www-data /var/www
    sudo chmod -R g+rw /var/www


    You should then be able to edit /var/www/ files without hassle.



    The first line adds you to the www-data group, the second line clears up any files with messed up ownership, and the third makes it so that all users who are members of the www-data group can read and write all files in /var/www.






    share|improve this answer





















    • 2





      This is a very bad idea for security and this advice should not be followed, for reasons explained in other answers. www-data is supposed to be an unprivileged group, without write access.

      – thomasrutter
      Nov 23 '16 at 23:45


















    7














    If you make /var/www writeable by its group and add yourself to the group, you will not have to use sudo while still being fairly secure. Try this:



    sudo adduser <username> www-data
    sudo chown -R www-data:www-data /var/www
    sudo chmod -R g+rw /var/www


    You should then be able to edit /var/www/ files without hassle.



    The first line adds you to the www-data group, the second line clears up any files with messed up ownership, and the third makes it so that all users who are members of the www-data group can read and write all files in /var/www.






    share|improve this answer





















    • 2





      This is a very bad idea for security and this advice should not be followed, for reasons explained in other answers. www-data is supposed to be an unprivileged group, without write access.

      – thomasrutter
      Nov 23 '16 at 23:45
















    7












    7








    7







    If you make /var/www writeable by its group and add yourself to the group, you will not have to use sudo while still being fairly secure. Try this:



    sudo adduser <username> www-data
    sudo chown -R www-data:www-data /var/www
    sudo chmod -R g+rw /var/www


    You should then be able to edit /var/www/ files without hassle.



    The first line adds you to the www-data group, the second line clears up any files with messed up ownership, and the third makes it so that all users who are members of the www-data group can read and write all files in /var/www.






    share|improve this answer















    If you make /var/www writeable by its group and add yourself to the group, you will not have to use sudo while still being fairly secure. Try this:



    sudo adduser <username> www-data
    sudo chown -R www-data:www-data /var/www
    sudo chmod -R g+rw /var/www


    You should then be able to edit /var/www/ files without hassle.



    The first line adds you to the www-data group, the second line clears up any files with messed up ownership, and the third makes it so that all users who are members of the www-data group can read and write all files in /var/www.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Oct 20 '16 at 15:24









    muru

    1




    1










    answered Jul 1 '11 at 0:41









    AzendaleAzendale

    8,80873962




    8,80873962








    • 2





      This is a very bad idea for security and this advice should not be followed, for reasons explained in other answers. www-data is supposed to be an unprivileged group, without write access.

      – thomasrutter
      Nov 23 '16 at 23:45
















    • 2





      This is a very bad idea for security and this advice should not be followed, for reasons explained in other answers. www-data is supposed to be an unprivileged group, without write access.

      – thomasrutter
      Nov 23 '16 at 23:45










    2




    2





    This is a very bad idea for security and this advice should not be followed, for reasons explained in other answers. www-data is supposed to be an unprivileged group, without write access.

    – thomasrutter
    Nov 23 '16 at 23:45







    This is a very bad idea for security and this advice should not be followed, for reasons explained in other answers. www-data is supposed to be an unprivileged group, without write access.

    – thomasrutter
    Nov 23 '16 at 23:45













    5














    Don'ts





    • Don't set file permissions to 777 (world-writable)



      This is a significant security flaw, especially if you enable server-side scripting such as PHP. Unprivileged processes should not be able to write to files that would affect the website or, in the case of server-side scripting being used, execute arbitrary code.




    • Don't add yourself as a member of the www-data group and give it write permissions



      The purpose of that group is that it is an unprivileged group that the server processes run as. They should only have read access to the website files where possible, for the same reasons as above.




    • Don't change the permissions of the Apache processes



      The Apache child processes run as the www-data user and group by default, and this should not be altered. This is just a way of giving them no write permission to the filesystem.



      In certain circumstances you want your server-side scripts to be able to write to files, in which case only those files should be made writable by www-data and care needs to be taken to ensure security.




    Dos





    • Set the files to be owned by yourself



      If you are the only one, or the usual one, to modify certain files on the website, then it makes total sense just to take ownership of those files. Set their owner to <your username>.



      You don't have to modify the server permissions for this, as the server will continue to get read-only access even when the files are owned by you.




    • Choose a sensible place to house the files (using DocumentRoot)



      If /var/www doesn't make sense, you are welcome to place them elsewhere. If they are specific to your own development or testing, you could place them in your home directory. Or you can set up some directories in /srv.




    • If you want to give group write access, create a new group for the purpose



      Don't re-use a system group, because these are typically designed to have the access they currently have, and no more, for security reasons.








    share|improve this answer






























      5














      Don'ts





      • Don't set file permissions to 777 (world-writable)



        This is a significant security flaw, especially if you enable server-side scripting such as PHP. Unprivileged processes should not be able to write to files that would affect the website or, in the case of server-side scripting being used, execute arbitrary code.




      • Don't add yourself as a member of the www-data group and give it write permissions



        The purpose of that group is that it is an unprivileged group that the server processes run as. They should only have read access to the website files where possible, for the same reasons as above.




      • Don't change the permissions of the Apache processes



        The Apache child processes run as the www-data user and group by default, and this should not be altered. This is just a way of giving them no write permission to the filesystem.



        In certain circumstances you want your server-side scripts to be able to write to files, in which case only those files should be made writable by www-data and care needs to be taken to ensure security.




      Dos





      • Set the files to be owned by yourself



        If you are the only one, or the usual one, to modify certain files on the website, then it makes total sense just to take ownership of those files. Set their owner to <your username>.



        You don't have to modify the server permissions for this, as the server will continue to get read-only access even when the files are owned by you.




      • Choose a sensible place to house the files (using DocumentRoot)



        If /var/www doesn't make sense, you are welcome to place them elsewhere. If they are specific to your own development or testing, you could place them in your home directory. Or you can set up some directories in /srv.




      • If you want to give group write access, create a new group for the purpose



        Don't re-use a system group, because these are typically designed to have the access they currently have, and no more, for security reasons.








      share|improve this answer




























        5












        5








        5







        Don'ts





        • Don't set file permissions to 777 (world-writable)



          This is a significant security flaw, especially if you enable server-side scripting such as PHP. Unprivileged processes should not be able to write to files that would affect the website or, in the case of server-side scripting being used, execute arbitrary code.




        • Don't add yourself as a member of the www-data group and give it write permissions



          The purpose of that group is that it is an unprivileged group that the server processes run as. They should only have read access to the website files where possible, for the same reasons as above.




        • Don't change the permissions of the Apache processes



          The Apache child processes run as the www-data user and group by default, and this should not be altered. This is just a way of giving them no write permission to the filesystem.



          In certain circumstances you want your server-side scripts to be able to write to files, in which case only those files should be made writable by www-data and care needs to be taken to ensure security.




        Dos





        • Set the files to be owned by yourself



          If you are the only one, or the usual one, to modify certain files on the website, then it makes total sense just to take ownership of those files. Set their owner to <your username>.



          You don't have to modify the server permissions for this, as the server will continue to get read-only access even when the files are owned by you.




        • Choose a sensible place to house the files (using DocumentRoot)



          If /var/www doesn't make sense, you are welcome to place them elsewhere. If they are specific to your own development or testing, you could place them in your home directory. Or you can set up some directories in /srv.




        • If you want to give group write access, create a new group for the purpose



          Don't re-use a system group, because these are typically designed to have the access they currently have, and no more, for security reasons.








        share|improve this answer















        Don'ts





        • Don't set file permissions to 777 (world-writable)



          This is a significant security flaw, especially if you enable server-side scripting such as PHP. Unprivileged processes should not be able to write to files that would affect the website or, in the case of server-side scripting being used, execute arbitrary code.




        • Don't add yourself as a member of the www-data group and give it write permissions



          The purpose of that group is that it is an unprivileged group that the server processes run as. They should only have read access to the website files where possible, for the same reasons as above.




        • Don't change the permissions of the Apache processes



          The Apache child processes run as the www-data user and group by default, and this should not be altered. This is just a way of giving them no write permission to the filesystem.



          In certain circumstances you want your server-side scripts to be able to write to files, in which case only those files should be made writable by www-data and care needs to be taken to ensure security.




        Dos





        • Set the files to be owned by yourself



          If you are the only one, or the usual one, to modify certain files on the website, then it makes total sense just to take ownership of those files. Set their owner to <your username>.



          You don't have to modify the server permissions for this, as the server will continue to get read-only access even when the files are owned by you.




        • Choose a sensible place to house the files (using DocumentRoot)



          If /var/www doesn't make sense, you are welcome to place them elsewhere. If they are specific to your own development or testing, you could place them in your home directory. Or you can set up some directories in /srv.




        • If you want to give group write access, create a new group for the purpose



          Don't re-use a system group, because these are typically designed to have the access they currently have, and no more, for security reasons.









        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 23 '16 at 23:49

























        answered Nov 23 '16 at 23:43









        thomasrutterthomasrutter

        26.8k46489




        26.8k46489























            5














            It's this simple. You neither need to enable apache 'UserDir' (not recommended) nor messing up with 'www-data' groups (apache group in case on Fedora)



            Just create your project directory inside /var/www/html



            cd /var/www/html
            sudo mkdir my_project


            Then just chown the project directory to your user.



            sudo chown your_username my_project


            Now you can start working on your project folder as a regular user with any editor, IDE of your choice. No more sudos : )






            share|improve this answer





















            • 1





              +1 That's what I do: change ownership not of /var/www itself, but of subdirectories.

              – fkraiem
              Oct 20 '16 at 15:33


















            5














            It's this simple. You neither need to enable apache 'UserDir' (not recommended) nor messing up with 'www-data' groups (apache group in case on Fedora)



            Just create your project directory inside /var/www/html



            cd /var/www/html
            sudo mkdir my_project


            Then just chown the project directory to your user.



            sudo chown your_username my_project


            Now you can start working on your project folder as a regular user with any editor, IDE of your choice. No more sudos : )






            share|improve this answer





















            • 1





              +1 That's what I do: change ownership not of /var/www itself, but of subdirectories.

              – fkraiem
              Oct 20 '16 at 15:33
















            5












            5








            5







            It's this simple. You neither need to enable apache 'UserDir' (not recommended) nor messing up with 'www-data' groups (apache group in case on Fedora)



            Just create your project directory inside /var/www/html



            cd /var/www/html
            sudo mkdir my_project


            Then just chown the project directory to your user.



            sudo chown your_username my_project


            Now you can start working on your project folder as a regular user with any editor, IDE of your choice. No more sudos : )






            share|improve this answer















            It's this simple. You neither need to enable apache 'UserDir' (not recommended) nor messing up with 'www-data' groups (apache group in case on Fedora)



            Just create your project directory inside /var/www/html



            cd /var/www/html
            sudo mkdir my_project


            Then just chown the project directory to your user.



            sudo chown your_username my_project


            Now you can start working on your project folder as a regular user with any editor, IDE of your choice. No more sudos : )







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 11 '18 at 15:07

























            answered Aug 6 '16 at 7:49









            Gayan WeerakuttiGayan Weerakutti

            1,8611328




            1,8611328








            • 1





              +1 That's what I do: change ownership not of /var/www itself, but of subdirectories.

              – fkraiem
              Oct 20 '16 at 15:33
















            • 1





              +1 That's what I do: change ownership not of /var/www itself, but of subdirectories.

              – fkraiem
              Oct 20 '16 at 15:33










            1




            1





            +1 That's what I do: change ownership not of /var/www itself, but of subdirectories.

            – fkraiem
            Oct 20 '16 at 15:33







            +1 That's what I do: change ownership not of /var/www itself, but of subdirectories.

            – fkraiem
            Oct 20 '16 at 15:33













            1














            chmod in /var on www to allow the owner access, and chown to make sure you own it. Probably a stupid idea, but it would definitely work.






            share|improve this answer



















            • 1





              Not a stupid idea, it's a sensible idea security-wise. Note: You don't need to (and shouldn't) change the permissions of /var, just /var/www and/or its contents.

              – thomasrutter
              Nov 23 '16 at 23:43


















            1














            chmod in /var on www to allow the owner access, and chown to make sure you own it. Probably a stupid idea, but it would definitely work.






            share|improve this answer



















            • 1





              Not a stupid idea, it's a sensible idea security-wise. Note: You don't need to (and shouldn't) change the permissions of /var, just /var/www and/or its contents.

              – thomasrutter
              Nov 23 '16 at 23:43
















            1












            1








            1







            chmod in /var on www to allow the owner access, and chown to make sure you own it. Probably a stupid idea, but it would definitely work.






            share|improve this answer













            chmod in /var on www to allow the owner access, and chown to make sure you own it. Probably a stupid idea, but it would definitely work.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jun 1 '11 at 3:59









            DanielDaniel

            1,39121326




            1,39121326








            • 1





              Not a stupid idea, it's a sensible idea security-wise. Note: You don't need to (and shouldn't) change the permissions of /var, just /var/www and/or its contents.

              – thomasrutter
              Nov 23 '16 at 23:43
















            • 1





              Not a stupid idea, it's a sensible idea security-wise. Note: You don't need to (and shouldn't) change the permissions of /var, just /var/www and/or its contents.

              – thomasrutter
              Nov 23 '16 at 23:43










            1




            1





            Not a stupid idea, it's a sensible idea security-wise. Note: You don't need to (and shouldn't) change the permissions of /var, just /var/www and/or its contents.

            – thomasrutter
            Nov 23 '16 at 23:43







            Not a stupid idea, it's a sensible idea security-wise. Note: You don't need to (and shouldn't) change the permissions of /var, just /var/www and/or its contents.

            – thomasrutter
            Nov 23 '16 at 23:43













            1














            You could start a www-session in a terminal by



            sudo su www-data


            Combined with a differently colored prompt*, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm (and editor and such) on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion.



            *) For a differently colored prompt with a differnt character, create a file /etc/prompt like this:



            # PROMPTING
            # When executing interactively, bash displays the primary prompt PS1 when it is ready to read a command, and the sec-
            # ondary prompt PS2 when it needs more input to complete a command. Bash allows these prompt strings to be customized
            # by inserting a number of backslash-escaped special characters that are decoded as follows:
            # a an ASCII bell character (07)
            # d the date in "Weekday Month Date" format (e.g., "Tue May 26")
            # D{format}
            # the format is passed to strftime(3) and the result is inserted into the prompt string; an empty format
            # results in a locale-specific time representation. The braces are required
            # e an ASCII escape character (033)
            # h the hostname up to the first `.'
            # H the hostname
            # j the number of jobs currently managed by the shell
            # l the basename of the shell's terminal device name
            # n newline
            # r carriage return
            # s the name of the shell, the basename of $0 (the portion following the final slash)
            # t the current time in 24-hour HH:MM:SS format
            # T the current time in 12-hour HH:MM:SS format
            # @ the current time in 12-hour am/pm format
            # A the current time in 24-hour HH:MM format
            # u the username of the current user
            # v the version of bash (e.g., 2.00)
            # V the release of bash, version + patchelvel (e.g., 2.00.0)
            # w the current working directory
            # W the basename of the current working directory
            # ! the history number of this command
            # # the command number of this command
            # $ if the effective UID is 0, a #, otherwise a $
            # nnn the character corresponding to the octal number nnn
            # \ a backslash
            # [ begin a sequence of non-printing characters, which could be used to embed a terminal control sequence
            # into the prompt
            # ] end a sequence of non-printing characters
            #
            # The command number and the history number are usually different: the history number of a command is its position in
            # the history list, which may include commands restored from the history file (see HISTORY below), while the command
            # number is the position in the sequence of commands executed during the current shell session. After the string is
            #
            # colors:
            # [...] wird benötigt, damit die shell weiß, daß hier kein printable output ist, und die Umbrüche richtig plaziert.
            #
            # ANSI COLORS
            CRE="[
            [K]"
            NORMAL="[[0;39m]"
            # RED: Failure or error message
            RED="[[1;31m]"
            # GREEN: Success message
            GREEN="[[1;32m]"
            # YELLOW: Descriptions
            YELLOW="[[1;33m]"
            # BLUE: System messages
            BLUE="[[1;34m]"
            # MAGENTA: Found devices or drivers
            MAGENTA="[[1;35m]"
            # CYAN: Questions
            CYAN="[[1;36m]"
            # BOLD WHITE: Hint
            WHITE="[[1;37m]"
            #
            # default:
            # postgres, oracle, www-data
            #
            # PS1=$BLUE"machine]->"$NORMAL\w"$BLUE ø $NORMAL"
            PS1=$BLUE"machine]:"$NORMAL\w"$BLUE > $NORMAL"
            #
            # root, stefan:
            #
            case "$UID" in
            '0')
            PS1=$RED"machine:"$NORMAL\w"$RED # $NORMAL"
            ;;
            '1000')
            PS1=$GREEN"machine:"$BLUE\w$YELLOW" > "$NORMAL
            ;;
            # default)
            # ;;
            esac


            and source it from /etc/bash.bashrc for instance.



            As additional tool to help distinction, you could always edit your files with an alias 'edit' or a symlink, which points, depending on your identity (taylor/www-data) to either gedit or mousepad, vim or pico. Or you could use different editor profiles, at least in gedit you may set your preferences to black text on white ground or white text on black ground for instance.



            I only have such a policy for working as root, so I'm not sure how good it will fit to working with www-data. Combined with ssh-sessions to differnt hosts, which have their own prompts, it didn't stop me from being sometimes wrong, but if it happens, I realize fast, what is wrong, and it happens rarely.



            note: The prompt-script is partly a copy of the manpage of bash.






            share|improve this answer
























            • This will work, and will not (if used carefully) negatively impact security, but may not be the most straightforward solution. It's a valid solution for some people though.

              – thomasrutter
              Nov 23 '16 at 23:47
















            1














            You could start a www-session in a terminal by



            sudo su www-data


            Combined with a differently colored prompt*, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm (and editor and such) on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion.



            *) For a differently colored prompt with a differnt character, create a file /etc/prompt like this:



            # PROMPTING
            # When executing interactively, bash displays the primary prompt PS1 when it is ready to read a command, and the sec-
            # ondary prompt PS2 when it needs more input to complete a command. Bash allows these prompt strings to be customized
            # by inserting a number of backslash-escaped special characters that are decoded as follows:
            # a an ASCII bell character (07)
            # d the date in "Weekday Month Date" format (e.g., "Tue May 26")
            # D{format}
            # the format is passed to strftime(3) and the result is inserted into the prompt string; an empty format
            # results in a locale-specific time representation. The braces are required
            # e an ASCII escape character (033)
            # h the hostname up to the first `.'
            # H the hostname
            # j the number of jobs currently managed by the shell
            # l the basename of the shell's terminal device name
            # n newline
            # r carriage return
            # s the name of the shell, the basename of $0 (the portion following the final slash)
            # t the current time in 24-hour HH:MM:SS format
            # T the current time in 12-hour HH:MM:SS format
            # @ the current time in 12-hour am/pm format
            # A the current time in 24-hour HH:MM format
            # u the username of the current user
            # v the version of bash (e.g., 2.00)
            # V the release of bash, version + patchelvel (e.g., 2.00.0)
            # w the current working directory
            # W the basename of the current working directory
            # ! the history number of this command
            # # the command number of this command
            # $ if the effective UID is 0, a #, otherwise a $
            # nnn the character corresponding to the octal number nnn
            # \ a backslash
            # [ begin a sequence of non-printing characters, which could be used to embed a terminal control sequence
            # into the prompt
            # ] end a sequence of non-printing characters
            #
            # The command number and the history number are usually different: the history number of a command is its position in
            # the history list, which may include commands restored from the history file (see HISTORY below), while the command
            # number is the position in the sequence of commands executed during the current shell session. After the string is
            #
            # colors:
            # [...] wird benötigt, damit die shell weiß, daß hier kein printable output ist, und die Umbrüche richtig plaziert.
            #
            # ANSI COLORS
            CRE="[
            [K]"
            NORMAL="[[0;39m]"
            # RED: Failure or error message
            RED="[[1;31m]"
            # GREEN: Success message
            GREEN="[[1;32m]"
            # YELLOW: Descriptions
            YELLOW="[[1;33m]"
            # BLUE: System messages
            BLUE="[[1;34m]"
            # MAGENTA: Found devices or drivers
            MAGENTA="[[1;35m]"
            # CYAN: Questions
            CYAN="[[1;36m]"
            # BOLD WHITE: Hint
            WHITE="[[1;37m]"
            #
            # default:
            # postgres, oracle, www-data
            #
            # PS1=$BLUE"machine]->"$NORMAL\w"$BLUE ø $NORMAL"
            PS1=$BLUE"machine]:"$NORMAL\w"$BLUE > $NORMAL"
            #
            # root, stefan:
            #
            case "$UID" in
            '0')
            PS1=$RED"machine:"$NORMAL\w"$RED # $NORMAL"
            ;;
            '1000')
            PS1=$GREEN"machine:"$BLUE\w$YELLOW" > "$NORMAL
            ;;
            # default)
            # ;;
            esac


            and source it from /etc/bash.bashrc for instance.



            As additional tool to help distinction, you could always edit your files with an alias 'edit' or a symlink, which points, depending on your identity (taylor/www-data) to either gedit or mousepad, vim or pico. Or you could use different editor profiles, at least in gedit you may set your preferences to black text on white ground or white text on black ground for instance.



            I only have such a policy for working as root, so I'm not sure how good it will fit to working with www-data. Combined with ssh-sessions to differnt hosts, which have their own prompts, it didn't stop me from being sometimes wrong, but if it happens, I realize fast, what is wrong, and it happens rarely.



            note: The prompt-script is partly a copy of the manpage of bash.






            share|improve this answer
























            • This will work, and will not (if used carefully) negatively impact security, but may not be the most straightforward solution. It's a valid solution for some people though.

              – thomasrutter
              Nov 23 '16 at 23:47














            1












            1








            1







            You could start a www-session in a terminal by



            sudo su www-data


            Combined with a differently colored prompt*, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm (and editor and such) on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion.



            *) For a differently colored prompt with a differnt character, create a file /etc/prompt like this:



            # PROMPTING
            # When executing interactively, bash displays the primary prompt PS1 when it is ready to read a command, and the sec-
            # ondary prompt PS2 when it needs more input to complete a command. Bash allows these prompt strings to be customized
            # by inserting a number of backslash-escaped special characters that are decoded as follows:
            # a an ASCII bell character (07)
            # d the date in "Weekday Month Date" format (e.g., "Tue May 26")
            # D{format}
            # the format is passed to strftime(3) and the result is inserted into the prompt string; an empty format
            # results in a locale-specific time representation. The braces are required
            # e an ASCII escape character (033)
            # h the hostname up to the first `.'
            # H the hostname
            # j the number of jobs currently managed by the shell
            # l the basename of the shell's terminal device name
            # n newline
            # r carriage return
            # s the name of the shell, the basename of $0 (the portion following the final slash)
            # t the current time in 24-hour HH:MM:SS format
            # T the current time in 12-hour HH:MM:SS format
            # @ the current time in 12-hour am/pm format
            # A the current time in 24-hour HH:MM format
            # u the username of the current user
            # v the version of bash (e.g., 2.00)
            # V the release of bash, version + patchelvel (e.g., 2.00.0)
            # w the current working directory
            # W the basename of the current working directory
            # ! the history number of this command
            # # the command number of this command
            # $ if the effective UID is 0, a #, otherwise a $
            # nnn the character corresponding to the octal number nnn
            # \ a backslash
            # [ begin a sequence of non-printing characters, which could be used to embed a terminal control sequence
            # into the prompt
            # ] end a sequence of non-printing characters
            #
            # The command number and the history number are usually different: the history number of a command is its position in
            # the history list, which may include commands restored from the history file (see HISTORY below), while the command
            # number is the position in the sequence of commands executed during the current shell session. After the string is
            #
            # colors:
            # [...] wird benötigt, damit die shell weiß, daß hier kein printable output ist, und die Umbrüche richtig plaziert.
            #
            # ANSI COLORS
            CRE="[
            [K]"
            NORMAL="[[0;39m]"
            # RED: Failure or error message
            RED="[[1;31m]"
            # GREEN: Success message
            GREEN="[[1;32m]"
            # YELLOW: Descriptions
            YELLOW="[[1;33m]"
            # BLUE: System messages
            BLUE="[[1;34m]"
            # MAGENTA: Found devices or drivers
            MAGENTA="[[1;35m]"
            # CYAN: Questions
            CYAN="[[1;36m]"
            # BOLD WHITE: Hint
            WHITE="[[1;37m]"
            #
            # default:
            # postgres, oracle, www-data
            #
            # PS1=$BLUE"machine]->"$NORMAL\w"$BLUE ø $NORMAL"
            PS1=$BLUE"machine]:"$NORMAL\w"$BLUE > $NORMAL"
            #
            # root, stefan:
            #
            case "$UID" in
            '0')
            PS1=$RED"machine:"$NORMAL\w"$RED # $NORMAL"
            ;;
            '1000')
            PS1=$GREEN"machine:"$BLUE\w$YELLOW" > "$NORMAL
            ;;
            # default)
            # ;;
            esac


            and source it from /etc/bash.bashrc for instance.



            As additional tool to help distinction, you could always edit your files with an alias 'edit' or a symlink, which points, depending on your identity (taylor/www-data) to either gedit or mousepad, vim or pico. Or you could use different editor profiles, at least in gedit you may set your preferences to black text on white ground or white text on black ground for instance.



            I only have such a policy for working as root, so I'm not sure how good it will fit to working with www-data. Combined with ssh-sessions to differnt hosts, which have their own prompts, it didn't stop me from being sometimes wrong, but if it happens, I realize fast, what is wrong, and it happens rarely.



            note: The prompt-script is partly a copy of the manpage of bash.






            share|improve this answer













            You could start a www-session in a terminal by



            sudo su www-data


            Combined with a differently colored prompt*, to make it more obvious that it is the shell of a different user, and a policy always to put the corresponding xterm (and editor and such) on - for example - the virtual desktop 4, so that you get used to it, to avoid confusion.



            *) For a differently colored prompt with a differnt character, create a file /etc/prompt like this:



            # PROMPTING
            # When executing interactively, bash displays the primary prompt PS1 when it is ready to read a command, and the sec-
            # ondary prompt PS2 when it needs more input to complete a command. Bash allows these prompt strings to be customized
            # by inserting a number of backslash-escaped special characters that are decoded as follows:
            # a an ASCII bell character (07)
            # d the date in "Weekday Month Date" format (e.g., "Tue May 26")
            # D{format}
            # the format is passed to strftime(3) and the result is inserted into the prompt string; an empty format
            # results in a locale-specific time representation. The braces are required
            # e an ASCII escape character (033)
            # h the hostname up to the first `.'
            # H the hostname
            # j the number of jobs currently managed by the shell
            # l the basename of the shell's terminal device name
            # n newline
            # r carriage return
            # s the name of the shell, the basename of $0 (the portion following the final slash)
            # t the current time in 24-hour HH:MM:SS format
            # T the current time in 12-hour HH:MM:SS format
            # @ the current time in 12-hour am/pm format
            # A the current time in 24-hour HH:MM format
            # u the username of the current user
            # v the version of bash (e.g., 2.00)
            # V the release of bash, version + patchelvel (e.g., 2.00.0)
            # w the current working directory
            # W the basename of the current working directory
            # ! the history number of this command
            # # the command number of this command
            # $ if the effective UID is 0, a #, otherwise a $
            # nnn the character corresponding to the octal number nnn
            # \ a backslash
            # [ begin a sequence of non-printing characters, which could be used to embed a terminal control sequence
            # into the prompt
            # ] end a sequence of non-printing characters
            #
            # The command number and the history number are usually different: the history number of a command is its position in
            # the history list, which may include commands restored from the history file (see HISTORY below), while the command
            # number is the position in the sequence of commands executed during the current shell session. After the string is
            #
            # colors:
            # [...] wird benötigt, damit die shell weiß, daß hier kein printable output ist, und die Umbrüche richtig plaziert.
            #
            # ANSI COLORS
            CRE="[
            [K]"
            NORMAL="[[0;39m]"
            # RED: Failure or error message
            RED="[[1;31m]"
            # GREEN: Success message
            GREEN="[[1;32m]"
            # YELLOW: Descriptions
            YELLOW="[[1;33m]"
            # BLUE: System messages
            BLUE="[[1;34m]"
            # MAGENTA: Found devices or drivers
            MAGENTA="[[1;35m]"
            # CYAN: Questions
            CYAN="[[1;36m]"
            # BOLD WHITE: Hint
            WHITE="[[1;37m]"
            #
            # default:
            # postgres, oracle, www-data
            #
            # PS1=$BLUE"machine]->"$NORMAL\w"$BLUE ø $NORMAL"
            PS1=$BLUE"machine]:"$NORMAL\w"$BLUE > $NORMAL"
            #
            # root, stefan:
            #
            case "$UID" in
            '0')
            PS1=$RED"machine:"$NORMAL\w"$RED # $NORMAL"
            ;;
            '1000')
            PS1=$GREEN"machine:"$BLUE\w$YELLOW" > "$NORMAL
            ;;
            # default)
            # ;;
            esac


            and source it from /etc/bash.bashrc for instance.



            As additional tool to help distinction, you could always edit your files with an alias 'edit' or a symlink, which points, depending on your identity (taylor/www-data) to either gedit or mousepad, vim or pico. Or you could use different editor profiles, at least in gedit you may set your preferences to black text on white ground or white text on black ground for instance.



            I only have such a policy for working as root, so I'm not sure how good it will fit to working with www-data. Combined with ssh-sessions to differnt hosts, which have their own prompts, it didn't stop me from being sometimes wrong, but if it happens, I realize fast, what is wrong, and it happens rarely.



            note: The prompt-script is partly a copy of the manpage of bash.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jun 1 '11 at 15:49









            user unknownuser unknown

            4,87122252




            4,87122252













            • This will work, and will not (if used carefully) negatively impact security, but may not be the most straightforward solution. It's a valid solution for some people though.

              – thomasrutter
              Nov 23 '16 at 23:47



















            • This will work, and will not (if used carefully) negatively impact security, but may not be the most straightforward solution. It's a valid solution for some people though.

              – thomasrutter
              Nov 23 '16 at 23:47

















            This will work, and will not (if used carefully) negatively impact security, but may not be the most straightforward solution. It's a valid solution for some people though.

            – thomasrutter
            Nov 23 '16 at 23:47





            This will work, and will not (if used carefully) negatively impact security, but may not be the most straightforward solution. It's a valid solution for some people though.

            – thomasrutter
            Nov 23 '16 at 23:47


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Ask Ubuntu!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f46331%2fhow-to-avoid-using-sudo-when-working-in-var-www%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Human spaceflight

            Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

            張江高科駅