I need to allow my local webserver (localhost) to read and write the /etc/network/interfaces file on a linux system (ubuntu).
The data manipulation of the file is done, I just need to know the best way of granting www-data the permission to do it.
I guess I could first log in as root and set permission for all to edit the file (not a big security risk since it is a mediaplayer and won't be accessed by any other user).
I could also do some nifty grouping of the user, I guess... not so seasoned with these linux things.
Anyone have a good suggestion, or input on why my suggested method is bad?
I don't know why would you want to do this, but generally groups are handy for this:
You create a new group, for example networking
then you change the group of the file to this new group (and check that it has g+rw permission)
finally you add www-data user to the networking group.
(And possibly relog, since permissions are often cached; this may not be needed for www-data)
Related
I am trying to learn some stuffs about permissions in Linux, but I am not sure I get the use of the first permission which is associated to current user.
I watched some tutorials but I didn't find my answer.
I suppose permissions in Linux are used when multiple persons with different roles are accessing a server, to give the proper permission to each of them.
So you have the command:
chmod 755 <filename>
"7" - You are setting your own permission here? what use have this? you can edit this permission anytime I suppose... . I guess "user" it is referring to directory/file owner.
"5" (1st) - I guess here you are set permission for the rest of the group and it is useful when you have more users in the same group.
"5" (2nd) - I think this is a little to much generic. For example you are hosting 2 web app on the same machine or 2 different systems on the same machine and there are dedicated teams which are administrating these. Wouldn't be proper to set permission for individual group on each location?
Sorry if my question is misleading.
Let me try to explain to the best of my little knowledge:
On linux, a user(or group) is primarily(if not entirely) defined by its permissions to do stuff (access files, execute commands) on the machine.
Everything a user "does" on the machine is actually done by a process(es) executing on user's behalf.
A process may not always do what it is supposed to do, either intentionally or due to a bug. This is where your user's permissions come into play.
For example, If you give yourself all the permissions. Then a process executing with your permissions may in worst case could do anything from stealing your passwords to accidently(or maliciously) wiping off your hard drive.
On a side note, this is precisely why running in root is considered a security risk and is the whole point behind creating an unprivileged user.
Hope I answered your question.
I'm trying to reimplement an existing server service in Node.JS. That service can be compared to a classic FTP server: authenticated users can read/create/modify files, but restricted to the permissions given to the matching system user name.
I'm pretty sure I can't have Node.JS run as root and switch users using seteuid() or alike since that would break concurrency.
Instead, can I let my Node.JS process run as ROOT and manually check permissions when accessing files? I'm thinking about some system call like "could user X create a file in directory Y?"
Otherwise, could I solve this by using user groups? Note that the service must be able to delete/modify a file created by the real system user, which may not set a special group just so that the service can access the file.
Running node as root sounds dangerous, but I assume there aren't many options left for you. Most FTP servers run as root too, for the same reason. Though, it means you need to pay a severe attention to the security of the code you are going to run.
Now to the question:
You are asking whether you can reimplement the UNIX permissions control in node.js. Yes you can, but Should Not! It is almost 100% chance you will leave holes or miss edge cases Unix core has already taken care of.
Instead use the process.setuid(id) as you mentioned. It will not defeat concurrency, but you need to think of parallel concurrency rather than async now. That is an extra work, but will release you of an headache of reinventing the Unix security.
Alternatively, if all of the operations you want to carry on filesystem involve shell commands, then you can simply modify them to the following pattern:
runuser -l userNameHere -c 'command'
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'd like to edit Solr configuration files on my linux box via a samba share. The files need to be tomcat6:mygroup, but when I edit the files via windows, it writes them as myuser:mygroup. Is it possible to change the write settings for a single samba share so it preserves the existing user, group and permissions?
Is this something that can be done via Samba configuration, or is something trickier needed?
You should include an appropriate force user statement into your smb.conf. I'm assuming your Samba share's name is smbshare:
[smbshare]
....
force user = tomcat6
....
You can find out more details via man smb.conf. The important points are: tomcat6 needs to be a user on the system. Your connection to the [smbshare] needs to take place with valid user credentials. Once connected all file operations will be performed under the credentials of tomcat6 though. (You don't seem to want an additional setting of force user = ..., which is also possible....)
Update: You said you wanted to "preserve the existing user, group and permissions". Note, that my suggestion doesn't do that. It forces all edited files to be owned by tomcat6:mygroup instead of preserving the original settings. Maybe this is good enough for your purpose.
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.