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?
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 have created quite a few deb files, i have no problems doing that and they all run beautifully. However, if i want to replace a file in users home directory I am unsure on how to do that.
I have tried making a postinst to rsync the files from a predefined location to home directory, but since the postinst file is being run as root ( due to the debian installer running as root ) it is being sent to the root home directory and not the user's home directory....
Here's an example of the deb file contents :
Debian Directory ---> Control File ----> Postint File
usr/share/desktop (directory with files inside)
The postinst file has the sync command to send those files to users home:
#!/bin/sh
rsync -av /usr/share/desktop/ ~/.config/desktop/
The problem is it is sending the files to Root/home... not the default users home :(
I don't have the username of the user since this will be used on many computers with different users, therefore I can't use sudo -u username.
So what do I do? how do i replace files in users home directory from deb install? Any help is much appreciated.
In a Bash script, ~ refers to the current user's home directory. The package installation scripts are always run as root, so that's what "current user" means in this context.
(You could argue that the package installation is probably initiated by a user running su or sudo, but in the general case, you cannot assume this to be the case.)
Modifying user files from a system package appears extremely suspicious in any event. If the need is genuine, this should probably not be approached as a system package installation question in the first place. What are you actually trying to accomplish?
Not only are you violating the basic principle that package management should not meddle with user files; a consequence of this arrangement is that the operation can only be performed once: If the user has installed the package, attempting to install it again does nothing (at least until you uninstall).
A more manageable and predictable approach would seem to be making the package provide this functionality, but leave it to the user to invoke the actual sync (overwriting) script as needed. Perhaps you want to hook it into the desktop startup scripts somehow.
Having said that, sudo exposes the invoking user's identity in $SUDO_USER so you could look for that, and simply fail if it is not set.
As an aside, package scripts should work with dash so you need to avoid bashisms - prefer $HOME over ~, for example.
I managed to find a workaround, although it is not exactly what I was looking for, but here is my solution, at least for now.
#!/bin/sh
#This will move the desktop settings to required folder.
szAnswer=$(zenity --entry --text "Enter your login username\nThis must be entered correctly\n" --entry-text "Enter name of profile to use:")
xfce4-terminal -e "sudo rsync -av /usr/share/Desktop/ /home/$szAnswer/.config/xfce4/"
exit 0
In other words, the user gets asked to enter his username, and the files get copied to that user's home directory. The advantage is that if he does have multiple users, it will use the correct user. The disadvantage is if he enters username wrong, even a spelling mistake, the install will fail.
But it does work, I have tested. If anyone has a better solution I eagerly await your suggestions.
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.
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.
The root user can install quicklisp successfully. Howvever the ordinary user cannot.
I do not know why. Could anyone here shed a light on me?
You do not need root privileges in order to use or install Quicklisp.
The “permission denied” error you're getting is a general Unix issue, not a Quicklisp one. It results from you having installed Quicklisp as root. Your ~/quicklisp directory is now owned by root while it ought to be owned by your non-root user account. The simplest solution is to remove the ~/quicklisp directory and start over without using sudo.
sorry did not catch it well with given short message.
I guess with root privilege, one can install the files to /usr or somewhere, while commonly ordinary user are not granted to do.
haven't be using quicklisp, but i guess running it does not require special privilege.