(I know this is a stupid question, but I simply cannot stop myself from
asking!)
From time-to-time, while doing some user things for files being served up by
an Apache server, it would be so nice to be able to run as user “wwwrun”.
For example, installing a new PlugIn into a TWiki site requires that I
extract an archive into a TWiki folder under document root. Since
everything in TWiki is owned by “wwwrun:www” (and others should not have
write access), I cannot do what is needed as an ordinary user. I have to
go to super user, extract the archive, and then chown the new files
to “wwwrun:www” so Apache can read and CGI scripts can update them. Life
would be so much easier if I could simply do that extract as “wwwrun”!
The obvious solution is to “su wwwrun”, but that requires a password, and I
do not know it. (It is definitely not the same as root password!) I
suppose I could change the password using YaST, but I am hesitant to do so,
wondering how that might affect Apache!
So… What simple and obvious thing am I completely overlooking?!?
wwwrun doesn’t have a password, which prevents any attempt from working.
This is good for a couple reasons. First, ‘wwwrun’ is the user on SUSE
boxes when Apache is installed, which it often is. As a result, since
it’s a known variable (like ‘root’), it is something that could
otherwise be tried with brute-force attacks and, since it’s not normally
used by humans, it wouldn’t be noticed most of the time if somebody did
get in or locked it out (since Apache comes up before logins are tried
and stays up until it is restarted or the box is restarted). Also
wwwrun is used for doing things permission-wise but Apache doesn’t need
to “login” with it. Again, this keeps it safe from attackers.
Also keep in mind that Apache does not often need write rights to files,
and doesn’t need to own them to serve them up. For example if my user
of ‘ab’ owns all the files in /srv/www/htdocs and they are group-owned
by ‘www’ with read-only permissions then somebody somehow exploiting a
bug in Apache cannot deface my site because none of the files are owned
by Apache to change permissions, and permissions are not such that
Apache’s user can modify the files. You can even have files set to be
user/group owned by completely different identities and Apache can still
see them if the ‘other’ flag is set to read, though personally I’d go
with the group option in case you ever have passwords in server-side
files like PHP or Perl. Usually (99% of my cases at least) Apache
shouldn’t be able to write any of the files it may serve because that
means somebody could write code to do “bad things” and have Apache then
execute them.
If you REALLY want to do all this, change the ‘wwwrun’ user line in
/etc/passwd so that /bin/false is set to /bin/bash, and then set the
password for that user (passwd wwwrun) and off you go.
Good luck.
Larry Bristol wrote:
> (I know this is a stupid question, but I simply cannot stop myself from
> asking!)
>
> From time-to-time, while doing some user things for files being served up by
> an Apache server, it would be so nice to be able to run as user “wwwrun”.
> For example, installing a new PlugIn into a TWiki site requires that I
> extract an archive into a TWiki folder under document root. Since
> everything in TWiki is owned by “wwwrun:www” (and others should not have
> write access), I cannot do what is needed as an ordinary user. I have to
> go to super user, extract the archive, and then chown the new files
> to “wwwrun:www” so Apache can read and CGI scripts can update them. Life
> would be so much easier if I could simply do that extract as “wwwrun”!
>
> The obvious solution is to “su wwwrun”, but that requires a password, and I
> do not know it. (It is definitely not the same as root password!) I
> suppose I could change the password using YaST, but I am hesitant to do so,
> wondering how that might affect Apache!
>
> So… What simple and obvious thing am I completely overlooking?!?
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> wwwrun doesn’t have a password, which prevents any attempt from working.
> This is good for a couple reasons. First, ‘wwwrun’ is the user on SUSE
> boxes when Apache is installed, which it often is. As a result, since
> it’s a known variable (like ‘root’), it is something that could
> otherwise be tried with brute-force attacks and, since it’s not normally
> used by humans, it wouldn’t be noticed most of the time if somebody did
> get in or locked it out (since Apache comes up before logins are tried
> and stays up until it is restarted or the box is restarted). Also
> wwwrun is used for doing things permission-wise but Apache doesn’t need
> to “login” with it. Again, this keeps it safe from attackers.
>
> Also keep in mind that Apache does not often need write rights to files,
> and doesn’t need to own them to serve them up. For example if my user
> of ‘ab’ owns all the files in /srv/www/htdocs and they are group-owned
> by ‘www’ with read-only permissions then somebody somehow exploiting a
> bug in Apache cannot deface my site because none of the files are owned
> by Apache to change permissions, and permissions are not such that
> Apache’s user can modify the files. You can even have files set to be
> user/group owned by completely different identities and Apache can still
> see them if the ‘other’ flag is set to read, though personally I’d go
> with the group option in case you ever have passwords in server-side
> files like PHP or Perl. Usually (99% of my cases at least) Apache
> shouldn’t be able to write any of the files it may serve because that
> means somebody could write code to do “bad things” and have Apache then
> execute them.
>
> If you REALLY want to do all this, change the ‘wwwrun’ user line in
> /etc/passwd so that /bin/false is set to /bin/bash, and then set the
> password for that user (passwd wwwrun) and off you go.
>
> Good luck.
I understand all of that. The problem is that the whole point of TWiki is
that document files are modifiable by users via CGI scripts, which execute
as user “wwwrun”. (Users, of course, cannot modify the CGI scripts
themselves; these can be modified only by “root” and specifically NOT
by “wwwrun”.) So the current permissions settings are appropriate, exactly
as recommended by the TWiki developers (http://www.twiki.org/).
I’m simply trying to save myself some manual (error prone) steps. At least
you have convinced me it would not be an utter disaster to set a password
(and shell access) for “wwwrun”. All I have to do now is decide whether it
is worth taking the slight security risk (someone cracking the “wwwrun”
password even though this would be a futile task in practically every other
system in the universe) to make my own life easier. And since I would
probably use root password anyway, I fail to see how there would be any
more exposure than exists right now!
One thing you can do to improve security if you do give wwwrun a password and a shell, is lock the account when the account is not in use. This can be done by passwd -l wwwrun. This prepends a ! to the encrypted password in /etc/shadow so that it will never match any entry, but retains the old password for unlocking when you want to use it. You could make sudo entries to let yourself do these steps without su.
The other thing you can do is su through root first, then su to wwwrun and you will not be asked for a password for wwwrun (obviously), nor does it need to have one.
su
su - wwwrun
You do have to have a valid shell for wwwrun though. You could make the second command a sudo no-password command for yourself so you only have to do the latter. And if you make a script or alias for the second, it becomes just one command.
Hi,
sorry was a bit in a hurry and didn’t read your complete post :shame: But I don’t know if it is a good idea to give the apache user a valid shell because of security reasons.
It affects security very little. If there is going to be a vulnerability, it is unlikely to depend on whether that account has a valid interactive shell specified in /etc/passwd, which is really information for the login process. If you can subvert a running process owned by that account, you can start any further processes from there. Having a password is a little bit risky as a weak one could be guessed, if you forgot to exclude wwwrun from sshd_config, and similar.
Monex wrote:
>
> the su way doesn’t function because wwwrun is not allowed to login on
> any ways. But the sudo way should do it:
>
> Code:
> --------------------
>
> su -
> sudo -u wwwrun -s
>
> --------------------
>
> first you have to become root and ten sudo to wwwrun with a shell
DUH! This works perfectly for what I want to do!
The problem was that after using su to get root privileges, if I created a
new file (by extracting the contents of an archive, for example), those
files were owned by root:root, and I would need to chown wwwrun:run. Using
the sudo command, however, new files are already owned by wwwrun:www.
OK, in the simplest case, I am trading 1:1 (chown command vs. sudo) but in
practice, I usually have to do this more than once, so it is a definite
simplification, even without creating a script.
BTW: I did not need to modify user wwwrun. No password, no shell. So
there is no (increased) security risk at all!
