To fix that particular issue is easy:
sudo chown -R root /var/lib/sudo
As for why that happened... I believe that when you were messing with permissions for /var/www
you somehow, by accident, changed permissions (and ownership) of all /var
tree, including /var/lib/sudo
. (I bet the user you were trying to set has id=33)
This may have many consequenses, the sudo warning message being just one symptom.
UPDATE
As for the consequences... it really depends on what (and where) you did. Many (but not all) files and folds in the /var
tree are owned by root:root
, and its basically impossible to know who each and every file and folder originally belonged to. Full reinstall would be the only feasible way to restore it.
If you changed only the /var/lib
tree, it narrows down the "damage", but not much: there are still hundreds of files there.
You can try to find out which command you issued caused this trouble, accesing your bash history:
gedit ~/.bash_history &
Maybe this will give a clue about what happened and its consequences
[I still would like to know if there is a better answear.]
I found a way that works, and the prompt will be kept on a single line:
at the end of your ~/.bashrc
add this:
function FUNCsudoOn() {
if sudo -n uptime 2>/dev/null 1>/dev/null; then
echo -ne "\E[0m\E[93m\E[41m\E[1m\E[5m SUDO \E[0m";
#echo #without newline, the terminal seems to bugout with lines that are too big... discomment this if you find any problems...
fi;
}
function FUNCpromptCommand () {
FUNCsudoOn
}
export PROMPT_COMMAND=FUNCpromptCommand
#export PS1="\`FUNCsudoOn\`$PS1" #this also works, use instead of PROMPT_COMMAND
EDIT: I found that sudo -n uptime
will update the sudo timeout, so everytime you hit the Enter key, that sudo time will be updated... That makes knowing the remaining time useless, as it will always be the configured one, defaulting to 15min...
and to find the best colors formatting for you taste you can use ScriptEchoColor with --escapedchars
option like:
echoc --escapedchars "@{nRlyo} SUDO " #that outputs below...
echo -e "\E[0m\E[93m\E[41m\E[1m\E[5m SUDO \E[0m"
to just stop the blinking remove \E[5m
like in \E[0m\E[93m\E[41m\E[1m SUDO \E[0m
Best 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 a single space in a wrong place, such as recursively deleting/ var/www/dir
, which means/
andvar/www/dir
, instead of/var/www/dir
—please do not attempt), 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 thewww-data
userchgrp -R www-data $HOME
(cob) - this allowswww-data
to read or write any files in the home directory. This is not keeping the Least Privilege rule in mindchown -R $USER:$USER /var/www
(kv1dr) - unless the world has read permissions on/var/www
, the webserver running underwww-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: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 wherewww-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.Correct previously created files (assuming you to be the only user of
/var/www
):(even safer: use
640
or2750
and manuallychmod 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:If your home directory has no execute bit (descend) set for
other
(for security reasons), change the group of it towww-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 needsudo
if you have previously added your user to thewww-data
group.)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: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