I have setup an SVN repository for use with Apache 2 via svnadmin create command and appropriate vhost configuration. I found that, in order to correctly use the repository, this must be owned by wwwrun user (or www group) or chmodded to 777.
I would like to ask if it's possible to explicitly tell Apache to impersonate another user when serving requests to a certain path (from vhost.conf), like with suphp extension, so I won't mess with permissions once I create a repository.
Thank you in advance
To impersonate another user, apache would need to have elevated privileges - this would miss the point of running apache with limited rights (as use wwwrun in your example) in the first place. Therefore, pick one of the following
Run apache as root (dangerous, since a compromised apache will compromise your entire system)
Make wwwrun member of the svnrepo group that you give access to your repository to
Create a suid binary and a corresponding apache module to allow apache to impersonate (very complicated, easy to mess up - that's how suphp does it)
Change the permissions of the repository itself to allow everybody, wwwrun, or the www group.
Quite frankly, I don't see the problem you're having with the second or last option. Why can't you allow wwwrun to access your svn repository?
Related
I plan to create a web interface to configure a part of my system, including some files owned by root. I will be a NodeJS server and I know that running it as root is not a good idea.
Any suggestions about how to perform that without performance and security issues?
Thank you.
I decided to create a specific script that will be owned by root with high restricted rights and allow a sudo on that script for a dedicated user without password so that could not log in (only root can do a su on it).
In the script i will perform wanted action (updte, upgrade, files copy, etc.)
Let's hope that scurity is good enought
I have user:nobody and group:nogroup set for apache in httpd.conf.
Since I also use my own user to manage files on ssh through Samba, I would like to have access to the www folder for read/write, and also allow apache to read these files.
Some folders should have apache's write permissions.
Should I leave apache as nobody|nogroup?
I was thinking I should set my own user under a group called say "webadmins" and set apache a new user called say "apache" under the same group. Then allow the group to read from all files, but only my user will have write files. Whenever apache would need a write permission inside a folder, I would manually change that. Is this a fair enough approach or am I missing something?
Thanks!
usually any daemon will need to access a number of ressources.
it is therefore good practice to run each daemon under a special user:group, rather than nobody:nogroup.
traditionally (e.g. on Debian systems) apache runs as www-data:www-data.
finally, user permissions take precedence over group permissions (which in turn take precedence over other permissions).
this means that a directory where the user does not have write perms but the user's group can write is effectively r/o for that user (but not for other members of the group)
I would like to use a callback feature of an SVN repository (Unfuddle) to ping a URL on my server whenever a commit has been made. I have a PHP script accepting the message and attempting to call a shell script to execute an 'svn update'.
The problem I'm facing is that Apache is running under user 'www-data' and does not have access to the local repository: '.svn/lock' permission denied. I have read all about setting SUID/SGID on shell scripts and how most *NIX OS's simply don't support it because of the security risks involved.
However I can set the SUID/SGID bit on the SVN binary file located at /usr/bin/svn. This alleviates the problem by allowing any user to issue SVN commands on any repository; not the most ideal...
My question is what's the most logical/sane/secure way to implement this type of setup and if I did leave the bits set on the svn binary does that open up a major security risk that I'm failing to realize?
Sorry for the long-winded post; this is my first question and I wanted to be thorough.
Thanks
There are 2 types of solutions for this kind of problem, polling or event driven.
An example of a polling solution would be to have a cronjob running on your server updating every N minutes. This would probably be the easiest to maintain if it works for you. You would sidestep the whole permissions issue by running the cron from the correct account.
The solution you covered is an event driven solution. They are typically less resource intensive, but can be harder to set up. An another example of an event driven solution would be to have www-data belong to an svn group. Set the SGID bit and chown the repository directory to the svn group. This should allow anyone in that group to check-in/out.
If you need to limit to updating, you can escalate privileges or change user temporarily. You use ssh single purpose keys (aka command keys) to ssh in as the user with the correct privileges. The single purpose key can then be used to do the update.
Another way to escalate privileges would be to use sudo -u [user] [command]. Update the /etc/sudoers file to allow www-data to escalate/change user to one that can perform the update.
Either way I would NOT use SUID/SGID scripts.
As CodeRich already said, you can set up a cron job to frequently update tue working copy(that's also the solution I would use).
Setting svn SUID/SGID is bad, because svn can write files everywhere in the file system (think of a public accessible repository containing a passwd and shadow file, checked out into your /etc). You could use a little suid wrapper program(which is SUID to your user account, not root), which chdir into your working copy and executes svn with the correct parameters there. You can look at ikiwiki which does this when it is used as a cgi.
Another way is to change the permissions of your working copy, so that the www-data user can create and write files there.
change the permissions on your working copy so that Apache can write to it. You have a directory you want to change, you need permissions to do so. Its that simple :)
The problem you then face is allowing any Apache user (or hacked page) to write all over your repo, not a good thing. So - you need to only allow a part of the system to write to it, and the best way to do that is to run your php script as the user who already owns the repo.
That's easily achieved by running the php script as a cgi, or fastcgi process. You can specify the user to use, it doesn't have to be www-data at all, though it does require a bit more setting up, you can have the best of event-driven and security as you're likely to get.
Here's a quick explanation of phpSuexec that does this.
Background: I remember at my old place of employment how the web server admin would always make me change the httpd-accessible file upload directories so that they were owned by apache:apache or nobody:nobody.
He said this was for security reasons.
Question: Can you tell me what specifically were the security implications of this? Also is there a way to get apache to run as nobody:nobody, and are there security implications for that as well?
TIA
There is a valid reason, supposing the httpd (Apache) was owned by root and belongs to the group root also, and that there was a vulnerability that was found in the code itself, for example, a malicious user requested a URL that is longer than expected and the httpd seg-faulted. Now, that exploit has uncovered root access which means, it has control over the system and hence a malicious user would ultimately seize control and create havoc on the box.
That is a reason why the ownership of the httpd daemon runs under nobody:nobody or apache:apache. It is effectively a preventative measure to ensure that no exploit/vulnerability will expose root access. Imagine the security implications if that was to happen.
Fortunately, now, depending on the Linux distribution, BSD variants (OpenBSD/FreeBSD/NetBSD) or the commercial Unix variants, the httpd daemon runs under a user group that has the least privileges. And furthermore, it would be safe to say that a lot of the Apache code has been well tested enough and stable. About 49% of servers across all domains are running Apache. Microsoft's IIS runs at 29% of the domains. This is according the the netcraft survey site here.
In another context, it shows that having a program running under least privileges would be deemed 'safe' and mitigates any possible chances of exploits, vulnerabilites.
This is the wrong site for this question. Ordinarily you would not want the source code to be owned by the same user as Apache. Should a security flaw in Apache or your server-side scripts arise, an attacker could maliciously modify your web site's files without privilege escalation.
The one exception would be file upload directories, as you said. In this case, you want Apache to make changes to that directory.
This morning, I tried to commit a revision to Subversion and found that all of a sudden I did not have permission to do so.
Can't move '/svn/db/txn-protorevs/21000-ga9.rev' to '/svn/db/revs/21/21001':
Permission Denied
Looking at the revs directory, I noticed that somebody had committed the 21000th revision, and the group write permission for the new directory is missing for some reason.
drwxrwsr-x 2 svn svn 24K 2008-10-27 10:04 19
drwxrwsr-x 2 svn svn 24K 2008-12-18 07:13 20
drwxr-sr-x 2 jeff svn 4.0K 2008-12-18 11:18 21
Setting the group write permission on that directory allows me to commit, so I'm good for another 1000 revisions. But why does this happen, and what can I change to make sure it doesn't happen again?
If you have more than one developer accessing the repository through the file:// protocol, you may want to look into setting up a Subversion server (using svnserve or Apache). With that solution, the server itself is responsible for all access and permissions on the repository files, and you won't run into this problem.
From the SVN Book:
Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful.
The best way to solve this problem is to access the repository through a server.
If you don't mind unencrypted communication (which seems to be the case since you're using file://), svnserve is very easy to set up:
svnserve -d -r /svn
See this reference for help in setting it up and configuring authentication.
The bummer is that you'll have to set up each user's authentication separately.
To hook up into your OS's authentication you'd need to set up a Apache SVN server, which is a little more complicated, see these general instructions. You can find specific instructions for your OS with some googling.
Finally, if you want the fastest route to preventing the group write permission being reset while still using file://, just have everyone set a proper umask (002) in their shell startup, or use svn through a wrapper script that sets it:
#!/bin/bash
# svnwrapper.sh
umask 002
/usr/bin/env svn $*
Be sure that this umask isn't a security problem in your environment.
The most likely cause is like Greg said. Someone is accessing the repository through the file:// protocol and has an overly restrictive umask.