See https://stackoverflow.com/questions/645659/how-do-you-htdigest-400-user-accounts
The easiest method, based on one of the suggestions in the top-voted answer, is probably this:
digest="$( printf "%s:%s:%s" "$user" "$realm" "$password" |
md5sum | awk '{print $1}' )"
printf "%s:%s:%s\n" "$user" "$realm" "$digest" >> "/etc/apache2/pw/$user"
I've used md5sum
from GNU coreutils and awk
rather than just md5
because it's what i have installed on my system and I couldn't be bothered finding out which package contains /usr/bin/md5
- you could also use sha512sum
or other hashing program.
e.g. if user=foo, realm=bar, and password=baz then the command above will produce:
foo:bar:5bf2a4095f681d1c674655a55af66c5a
htdigest doesn't do anything magical or even unusual - it just outputs the user, realm, and password in the right format...as the command above does.
Deleting the digest for a given user:realm instead of just adding one, can easily be done with sed.
sed -i -e "/^$user:$realm:/d" "/etc/apache2/pw/$user"
And updating/changing the digest for a user:realm can also be done with sed in combination with the method above to generate the digest line. e.g.
digest="$( printf "%s:%s:%s" "$user" "$realm" "$new_password" |
md5sum | awk '{print $1}' )"
sed -i -e "/^$user:$realm:/ c$user:$realm:$digest" "/etc/apache2/pw/$user"
This is very easy to accomplish:
#!/bin/sh
[ "$(whoami)" != "root" ] && exec sudo -- "$0" "$@"
When the current user isn't root, re-exec the script through sudo
.
Note that I am using sudo
here instead of su
. This is because it allows you to preserve arguments. If you use su
, your command would have to be su -c "$0 $@"
which would mangle your arguments if they have spaces or special shell characters.
If your shell is bash, you can avoid the external call to whoami
:
(( EUID != 0 )) && exec sudo -- "$0" "$@"
Best Answer
sudo
also allowsNOPASSWD
on specific entries in the /etc/sudoers configuration, if you can get to that. Like:This will give userA full access to userB without password. Should probably only be used if userA can be trusted to lock his screen whenever leaving it …
Alternatively, you can give userA access to only certain scripts. For instance:
This lets userA run any command in the directory /home/userB/scripts-for-userA/ as userB. It's still only as secure as those commands are, though.