https://github.com/mongodb/mongo/blob/master/debian/mongodb-org-server.postinst
I could see in the above link that mongodb has created a newuser named 'mongodb'.and I got to know that many bigger projects run their project as a custom user (here as a user 'mongodb').I wrote a small application in python and running it as sudo right now,I would like to create a new custom user for my application and run the application as the custom user.how does actually bigger projects acheive this .what is the command they use to make run the whole application or package as a custom user?
In a whole lot reading about this I found that we could use sudo -u <username> <command>
or by setting euid or uid by seteuid() function. but I want to know how actually real projects implement it and follow that standard way in my project.
As in the file you linked they change the owner of the executable to their custom
using chown so you could use that in a post-installation script (a script that will configure what is necessary for your application to run correctly)
Related
my application is required update its program files when it detects a new version on the server. The update mechanism is performed by the application itself, and it replaces old code with new code in the same directory. Which directory in linux is best suited for this? If there is a standard directory which has write access by default(analogous to %AppData%\Local for windows), I would like to know which one it is.
I have tried using /var/<my-app-name-here> and /opt/<my-app-name-here>, but none of these directories have write access by default. The only way I can use them update files in them is if the user uses sudo, so i would just like to avoid making those problems by just installing to a directory with write access to begin with.
I am using a tool called jpackage to make the .deb file which install the application.
Within a tcl script, is there any way to do the command "sesu username" (or equivalent) to change the user the tcl script is running as?
For example, I run RunAnotherScript.tcl as user myusername (low permissions) and want it to sesu to user weblogic, because that user has the required permissions to run another script.
I'm a beginner at tcl... so the more information the better.
Probably the easiest thing to do is put the commands that are to be run as another user in a separate script. This also helps keep the logic between the low permission user and the high permission user separate. Then,
exec sesu weblogic -c RunWebLogicScript.tcl
Tcl does not include this functionality as a core command.
However, it is straightforward to write a compiled extension to add it in. A reference implementation of "setuid" can be found in the tclhttpd source
i am trying to write a custom (GUI) program installer which needs to run as a specific (system) user (without a home directory) - let's call him "installer". Things i have tried or pondered to achieve this in a couple of different ways:
launching the GUI installer app as user "installer" through (gk)su(do) (-u). the problem is that a. these commands are not available on every
distribution or do not behave the same everywhere thanks to internal aliases, and b. the x server does not allow me to connect as a different user without some potentially insecure "xhost +" modification (the old "cannot connect to X server :0.0" problem).
avoiding the X server for the installer routine and create a separate (CLI) binary for the chmod/file copy process, while the GUI runs in current user mode. the problem is that i have to give the password to the (sudo -S) command in clear text, which shows up in the logs, so not a good idea either.
several command combinations of export display, .Xauthority, xhost and anything i could find on stackoverflow, without much success.
so, what do i actually need?
a distro-independent, secure way of launching a GUI application as another (non-root, but "/home"-less system) user
an elegant way of asking the current user for the password of user "installer"
a solution that does not require the current user to enter the root password first, or install the application as root.
i'd be thankful for any thoughts on the matter.
[edit] to clarify, i do not rally want to install new programs into the established linux file structure. The whole setup is this:
I have a main program that will be installed by the root. this program can be extended by modules.
these modules will be installed into a custom folder (let's call it "/progmodules") which is owned by the "installer" user. the goal is to have authorized users to be able to install new modules, without giving them full root access.
any users who want to install new modules should be able to run the installer GUI app, enter the "installer" user password, and then have the files transferred.
I am creating a WordPress framework that has an auto update facility. When the system updates the framework, it downloads a .zip file (works ok, stored in a temp folder), and afterwards tries to extract that zip file to a place within the theme. When unzipping, it throws an error complaining about not being able to create a directory ("mkdir_failed").
The parent of target folder has permission "775" for user "bitnami" and group "bitnami";
root#linux:/home/bitnami# ls -al /opt/bitnami/apps/wordpress/htdocs/wp-content/themes/nexus
...
drwxrwxr-x 6 bitnami bitnami 4096 Oct 23 14:02 nexusframework
...
And I tried to put the "daemon" user in the "bitnami" group;
usermod -a -G bitnami daemon
Which indeed is assigned correctly I would say, as i see:
root#linux:/home/bitnami# id daemon
uid=1(daemon) gid=1(daemon) groups=1(daemon),1000(bitnami)
So; if the "daemon" user is in the "bitnami" group and the folder has 775 access rights, then why does it fail with "mkdir_failed"?
(note; assigning "777" to the parent folder solves the problem, but this is not an option because of security).
Thanks!
- Gert-Jan
update;
After doing more investigation on Linux in general, I read that Linux automatically creates a 'private' group for each user (so bitnami group for the bitnami user, etc.). I don't know if the problem is caused by the fact that I was trying (and apparently succeeded?) to add other users to the same group or not.
update;
See my answer below on how I resolved my issue.
Ok, thanks for all the comments. I eventually decided not to continu my investigation but to head for another direction, as having to rely on the container's folder to have "775" permission would be unwise for the framework (many clients would have 755 instead, so getting this to work for a group is nice but would eventually not solve my problem).
Instead I further investigated how WordPress themselves download and unzip themes and decided to follow that route.
The key problem i was trying to tackle, was to not have the unzipped files be owned by the 'daemon' user, but by the 'bitnami' user. The reason why it "impersonated" to the daemon user, was because i manually told the code to use the "direct" fs_method (as it appears, WP offers various ways to interact with the filesystem, where the easiest one is 'direct', see here). However, using the 'direct' FS_METHOD is the core reason why I have this problem, as that one will use the credentials of the webserver (the 'daemon' user in my case). So by using a different FS_METHOD, I know am able to unzip the files in the folder, using the correct 'bitnami' user (since the container is owner and has permissions (775, or 755 wouldn't matter) now my problem is solved. Note that instead of writing directly to the filesystem, now PHP will use FTP (see here).
Does it work if you change the group of the folder to daemon?
chgrp -R daemon /opt/bitnami/apps/wordpress/htdocs/wp-content/themes/nexus
I am creating a graphical installer that should run on Linux. Installing should consist of copying files to some places in /usr. Currently the installer is written in Python.
How can I escalate the privileges of my installer when I need to copy files? I looked at PolicyKit but
a) there doesn't seem to be a generic "install files" action-id for PolicyKit
b) of the action ids I can use, I don't think they are standard across distros
I also looked at PAM and I have code that uses libpam but I can't seem to do anything with it. After authenticating my user (by providing username and password) I don't have write access to /usr. I tried changing my user with os.setuid(0) after authentication but I get an error from the OS.
Also, strangely, it doesn't seem to matter what service I provide to pam_start. As long as the username and password are correct I can pass anything I want. I see I have /etc/pam.d/sudo. The below code is simplified, the password is correctly stored in a pam_conversation object and I do pass a handle object.
pam_start("my_user", "my_pass", "sudo_garbage_12345");
works just as well as
pam_start("my_user", "my_pass", "sudo");
That is, they both succeed.
As a last resort I can probably execute gksudo or kdesudo but I don't want to be tied to those programs. Requiring users to invoke my installer with sudo is a (very) last resort.
You might be better off wrapping RPM with a front end that takes the user options and invokes RPM to do the hard work. This also gives you infrastructure for managing dependencies and plays nicely with the existing package management system. If you need to run on a .deb based system (Debian or Ubuntu) you may also need to consturct a .deb and put some mechanism in the front end that works out which package management system is active.
Granting random users access to root privilege is generally viewed as bad form on Linux or Unix systems (or any multi-user system for that matter) as it is a significant security risk. However you do have the option of letting the user install it under their home directory (~/bin) if they don't have root access or sudo permissions that allow them to write to system areas. In this case you can require them to install it as root if they want to install in /usr/bin but permit them to install it under their home directory for their own use if they don't have root privileges.
For a graphical installer, stick with a graphical environment. Use gksudo or kdesudo if they are available, otherwise fail with an error dialog saying they need root. People (newbies in particular) will download your installer and double-click to launch it from their desktop, and you need a graphical way to ask them for their password. You don't want to pop open a terminal on them.
Given that, don't do sudo for them even if they are running from the terminal. Just output an error saying you need root and exit. If the user is already at the command prompt (like I most likely would be), I already know how to sudo or su myself into root if I want to do so. I promise you you will most likely ruffle some feathers if you attempt to make an experienced user root when they can do it themselves.
If you INSIST on doing a sudo yourself from within your installer, for God's sake please force a 'sudo -K' before you do to remove the previous timestamp. If you don't do this, and I have sudo'd recently, you will run your installer with me as root without my knowledge (since I don't expect that to happen). A 'sudo -K' will force a prompt that I can then decide whether I want to proceed as root or not.
The best way in this case is to use su within your program. Redirect inputs/outputs and you're good to go!