Cfxtrjtrk

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.

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.

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.

  
  

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 : )

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.

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.