I'd like to read/write files using nodejs that live in a protected directory (/etc/apache2/sites-available). I understand that I can run the script with sudo but the idea of that makes me worried. Is there some way I can have node try to elevate for certain functions/calls without having the whole script run with root access?
If you do not provide elevated rights to your script, the script will be unable to mysteriously obtain those rights out of the thin air.
Granted you still need to modify the files, then consider giving write permissinos to your app.
If you are running app as user joe, and owner of sites-available files is root, then do: chown -R joe:joe sites-available.
But if some other user already uses those files, then you might get into permissions conflict. In this case, you can workaround using shared group, or SSH as that user.
Shortly, there are several ways of achieving your goal. But it is completely unrelated to Node.js technology, and all about linux, chown and chmod.
Related
I wrote Postinst script for changing owner and file permission:
chown -R $(whoami) ~/Desktop/my_file.desktop
chmod 777 ~/Desktop/my_file.desktop
but after installation it does nothing.
I'm really not getting what part of script is wrong. Please tell how to get dynamically username in Postinst script?
Package installation runs as root, unconditionally. There is no concept of an invoking user; indeed, the package installation may happen e.g. before any user accounts exist on the box.
It's extremely unclear what you actually hope to achieve, but it looks like perhaps your package should simply install a script which then performs the task when the user runs it. This will also conveniently create a file which is already owned by the current user, without any chown trickery.
Even if a user exists, there is no guarantee that they have a Desktop directory in their home directory, or that they are currently, or ever, logged in using a GUI.
Finally, whatever you are attempting to do, chmod 777 is wrong and dangerous. You should absolutely not assign write access for everyone, to anything, ever.
(Okay, so there are two or three obscure scenarios related to system administration where this is actually required and useful; otherwise it should probably be technically impossible in the first place.)
I just installed Symfony CMF (standard edition 1.1) on a Linux VPS running Ubuntu 13. Everything is installed without errors but I always end up with a permission problem regarding the /app/cache & /app/logs folder.
As far as I know I installed the CMF as user root and the frontend is using user www-data, The only way to get it working without problems is by using these commands;
sudo chown -R :www-data app
sudo chmod g+s app
sudo setfacl -dR -m g::rwX app
chmod -R 777 app
After that it works perfectly but I am sure that from a security point of view this is not the correct way to do this.
So, I hope that anyone who has experienced this problem can provide me with a secure and correct method of solving the /app/ permission problem.
If I need to provide more information or show some configurations, I will gladly provide it as I need to solve this minor issue that is blocking the launch of my project.
This is explained in detail in the symfony documentation. Note that for images, we use the Imagine bundle, so you also need to set permissions on web/media/cache.
Usually you do not want to do things like deployments or git checkout as root, but with a non-privileged user. It is a good idea to have the webserver run under a different user, so that it can not just edit PHP files, to limit the potential damage in case there is a security issue in the webserver or your application.
I'm running into an issue where I do not have write access to the /var directory on a UNIX environment, and InstallAnywhere doesn't provide me the option of writing the .com.zerog.registry.xml to any other location for a product installation. Is there a parameter out there that allows for this file to be written to a different directory?
According to the IA docs:
If logged in as root, the global registry is located in \var.
If logged in as a user, it is located in the user’s home directory.
So, if you're running as root and can't write to /var, it sounds like a permissions problem with the /var directory, independent of IA. Check the permissions on /var.
If you're running as a non-root user, then the registry shouldn't be going to /var, but to $HOME/.com.zerog.registry.xml (FWIW, I just checked one of our test Linux boxes and found .com.zerog.registry.xml under both /var and under test-user $HOME directories. The docs appear to be correct).
I've also seen some very strange behavior if IA is low on space in $TMP. Make sure you have plenty of space there.
Also, have you considered running the installer with sudo, or the graphical equivalents kdesudo (KDE) and gksu (Gnome)? Those might get you where you want to go.
I need to grant jenkins user permission to access some specific directories like usr/lib or usr/local/include so that he can copy some files into those directories during the execution of some Jenkins jobs. How can I do that?
The idea that something accessed from the web can overwrite system files is very scary (and insecure), but I think you would need to grant the user under which Jenkins is running the privileges need to write there.
Again, there are good reasons why ordinary user's aren't granted permissions to write to those directories. You might want to consider running the job in a chroot jail. That way, if something goes wrong, you won't destroy your system.
For specific task i would say use sudo
You mentioned usr/lib or usr/local/include directories, and if your goal is to install some tools and packages during job execution, you could install it locally into your job workspace (for example, into .local directory) and after that make your jobs work with those directories by setting environment variables like LD_LIBRARY_PATH, CFLAGS, etc.
I'm writing an install script in bash for an application on Linux.
This script copies some files into /usr/bin and /usr/share, so it needs to be executed by a root user, furthermore it makes an hidden directory in the $HOME dir for configuration files.
Here is the problem: if a normal user wants to install the program, he needs to be root. But if he is root, the $HOME directory will be /root/ instead of /home/username.
...and, further, if UserA installs the software, but UserB runs it, UserB won't have the hidden directory under /home/UserB. Also, the hidden directory under /home/UserA will be owned by root, not userA.
So, you need to have the application create the hidden directory, not the installer.
Another possible option is not to install in the system directories; one possible alternative location is /usr/local. However, even that can require root privileges. Think about whether it can be installed in other places, and how it could locate its materials.
However, requiring root privileges to install is not the end of the world - a nuisance for some, but not completely out of order. But requiring everyone who uses to have root privileges is way out of order - and if everyone who uses it needs to run the installer, that is bad.
Final point (for now): if you use sudo, it does not change the value of $HOME, even as you acquire root privileges. However, requiring everyone who uses your application to have sudo privileges is not a good thing either.
Must you use $HOME? Maybe you could prompt for the username and install to ~$username instead?