I work in a shared web development environment. My team frequently creates new files and folders on the server, but they always need to change group permissions afterward.
For default permissions on new files, I set umask 002 in the bashrc. BUT for default permissions on new directories:
$ sudo chmod g+s /var/www
New directories within /var/www now display as:
drwxrwsr-x 2 user www-data 4096 2010-10-14 08:49 test
Now, this setup works correctly, i.e. new files and directories are group-writable by default. Are there any security issues to using sgid in this setup? Being extra cautious because I don't fully understand setuid risks.
My understanding of your setup is that every file created will be with permissions 0775. You set the SGID (Set Group ID) bit to the /var/www directory which will force any file/directory created inside it to inherit the existing group owner rather than the owner creating it. As for the SUID (Set User ID) bit it doesn't seem like you're using it unless I've mistaken your description.
I'm assuming you have every user part of the 'www-data' group (default Apache group) and that's what's making everything run smoothly now.
The security risks I see is that now Apache (part of 'www-data' group) has full access to every file under your web root folder. If you happen to have a public script with a security hole, or Apache is somehow compromised, your entire /var/www folder (at least) is at it's mercy.
Instead I would create a separate group (say 'developers') and make your team a part of that. Change the group owner of your /var/www folder to 'developers' and leave Apache with the default access ('r-x' for directories, 'r--' for files) and selectively assign higher permission only where you need to (cache, uploads, etc).
Hope this helps, it's my first response/answer, and way past my bedtime :)
Related
How can I tell if the settings files associated with a Mosquitto instance, have been properly applied?
I want to add a configuration file to the conf.d folder to override some settings in the default file, but I do not know how to check they have been applied correctly once the Broker is running.
i.e. change persistence to false (without editing the standard file).
Test it.
You can run mosquitto with verbose output enabled, which will generally give you feedback on what options were set, but don't just believe that.
To do that, stop running Mosquitto as a service (how you do this depends on you setup) and manually run it from the shell with the -v option. Be sure to point it at the correct configuration file with the -c option.
That's not enough to be sure that it's actually working properly. To do that you need to test it.
Options have consequences or we wouldn't use them.
If you configure Mosquitto to listen on a specific port, test it by trying to connect to that port.
If you configure Mosquitto to require secure connections on a port, test it by trying to connect to the port unsecured (this shouldn't work) and secured (this should work).
You should be able to devise relatively simple tests for any options you can set in the configuration file. If you care if it's actually working, don't just take it on faith; test it.
For extra credit you can bundle the tests up into a script so that you can run an entire test suite easily in the future and test your Mosquitto installation anytime you make changes to it.
Having duplicate configuration options with different values is a REALLY bad idea.
The behaviour of mosquitto is not defined in this case, which value should be honoured, the first found, the last? When using the conf.d directory, what order will the files be loaded in?
Also will you always remember that you have changed the value in a conf.d file in the future when you go looking?
If you want to change one of the defaults in the /etc/mosquitto/mosquitto.conf file then edit that file. (Any sensible package management system will notice the file has been changed and ask what to do at the point of upgrade)
The conf.d/ directory is intended for adding extra listeners.
Also be aware that there really isn't a default configuration file, you must always specify a configuration file with the -c command line option. The file at /etc/mosquitto/mosquitto.conf just happens to be the config file that is passed when mosquitto is started as a service when installed using most Linux package managers. (The default Fedora install doesn't even setup the /etc/mosquitto/conf.d directory)
I'm totally newbie in Beanstalk. I'm developing a web application in which a sealed and black-box plugin is used. That plugin needs a physical path with full permission to use for cache.
Any solution?
You can use the .ebextensions files in the main project that will, for example, create a directory and change the access rights to it. It is not clear from your question how you install the plugin (e.g. is it a service that is loaded after the web application is installed or is it part of the web application).
Execute a command in the .ebextensions file such as in:
How to grant permission to users for a directory using command line in Windows?
You'll find a introduction into container customization in
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-windows-ec2.html
Be careful about the format of the files (ie. spaces, no tabs, the best is to edit it in a separate text editor). Experiment with simple commands first, so that you get the hang of how the commands are executed.
Note: The ebextensions commands are executed for each deployment, so your script should check if the directory exists already and only create it if it doesn't. Otherwise the execution will fail as you try to create a directory that exists already. In a second step you can add the permissions.
Recently had the pleasure of picking up a VPS over # DigitalOcean. It's a Ubuntu 14.04 running Rails + Nginx & Unicorn.
I wanted to work with Sublime, as I have locally, so I installed the commercial SFTP plugin. I was able to successfully gain remote access to my VPS, and I even downloaded the rails folder locally. Now is where it gets difficult though, and I need some help.
How I do I keep the local folder and the remote folder in sync?
Right clicking on the folder via Sublime offers some options like, sync Local -> Remote, which seems like what I want, except that every upload ends in failure (Permission denied).
Am I supposed to be doing this local to remote sync? Or am I off base here? If I'm on base, why do I get permission denied?
Probably, the user you're using for the SFTP connection has read permissions on the folder you're working on, but is not allowed to write.
For this reason, you were allowed to download your remote folder, but no longer allowed to write in it (upload).
You can check this by running ls -ld /path/to/rails/ and reading the first part (for example, it could be drwxr--r--). If needed, here you can learn more about file system permissions.
If it's a permission problem, you can solve it in different ways, but you should consider how each solution could impact the security and/or functionality of your application:
You could change the owner of the rails directory to match the Sublime SFTP user (see man chown), and ensure the owner of the rails user has write access on it (sudo chmod o+w /path/to/rails)
You could use a different user for Sublime SFTP access (one that has write permissions on the rails folder)
You could add the Sublime SFTP user to the group of the rails folder (useradd -G {group-name} username) and then grant the folder group write access (sudo chmod g+w /path/to/rails)
I'm trying to write local checks for a Check_MK instance on a computer with OMD installed. I don't have admin rights on this machine, so I work as an OMD site like this:
sudo omd su $MY_SITE
And, like my standard user, the site user does not have admin rights either.
In the Check_MK documentation for writing agent-based checks I find that I have two options for doing this:
Editing /usr/bin/check_mk_agent, which is impossible with the rights I have or
Creating a script in /usr/lib/check_mk_agent/plugins/, which is also impossible because this folder is only writeable to root.
When I run cmk --paths I see that there's a folder for "locally installed agents and plugins" at $MY_SITE_HOME/local/share/check_mk/agents/. This folder has a subfolder named plugins. If I put a script in there, however, its output doesn't show up when I run check_mk -d localhost. It is set to be executable and it does produce valid output, as far as I can tell:
<<<helloworld>>>
Hello world!
Am I putting the script in the wrong folder? Is it necessary to have admin rights in order to write agent based checks in Check_MK?
One way of doing this without admin rights would have been to edit main.mk to include include a new datasource program. I would have liked to have a local folder that was analog to /usr/lib/check_mk_agent/plugins/, but it seems that this is not possible. I ended up having one of our admins give me the rights to /usr/lib/check_mk_agent/plugins/.
i’m trying to create a custom module: i followed instructions of this tutorial: http://blog.baobaz.com/en/blog/magento-module-create-your-own-controller. but even copying exactly all the posted code, i can’t see the new module in backend (System->Configuration->Advanced->Advanced->Disable Modules Output). i thought could be a permission problem (i created all files with sudo permission). so i changed owner and group of all files and dirs created to www-data (sudo chown -R www-data:www-data ...), and also i gave x permission to all .xml files, but still i can’t see the new module in that list. i’ve redo once againg all the tutorial steps but nothing changed. any suggestion?
Thanx, luke