Re: Maintainer scripts: execute command as another user: use sudo or su?
2014-03-02 0:41 GMT+01:00 gregor herrmann gre...@debian.org: On Sat, 01 Mar 2014 22:55:20 +0100, Emilien Klein wrote: One minor challenge that I faced is that I couldn't get the commands to run using su. With the help of Karsten Hilbert I understood that the issue was that the user being a system user, she didn't have a shell (default shell for new system users is /bin/false). That's what Russ already mentioned in https://lists.debian.org/debian-mentors/2014/02/msg00499.html :) Indeed. I thought I was subscribed to the list, looks like that's not the case as I missed his response ;) Thanks all for your help. su is now used, and new gnuhealth package is already uploaded to sid. +Emilien P.S.: Please CC me as I'm not subscribed to the list. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canqxmqhafcm_mqfjhcrmpglned2r2mzjbb7czjxzsbzh2s4...@mail.gmail.com
Re: Maintainer scripts: execute command as another user: use sudo or su?
On 02/27/2014 03:37 PM, David Kalnischkies wrote: On Wed, Feb 26, 2014 at 04:07:35PM +0100, Emilien Klein wrote: In the pre- and postinst scripts, a command has to be performed as that user (e.g. make a backup of the database). […] I am wondering what the best way is to fix this. I see 2 solutions: 1. Depend on sudo 2. Use su --command instead Beside what others already said: As you said it is run in preinst scripts you would need to pre-depend on sudo – and you would need to discuss this first on debian-devel@ as strongly recommend by debian-policy (§3.5 and §7.2). The outcome of this discussion would probably be that you should use su… su on the other hand is 'free' to use as it is provided by the essential login package, so no dependency is needed at all. I have made the switch to su instead of sudo. One minor challenge that I faced is that I couldn't get the commands to run using su. With the help of Karsten Hilbert I understood that the issue was that the user being a system user, she didn't have a shell (default shell for new system users is /bin/false). Running the commands as su --shell /bin/sh -c COMMAND USERNAME works as expected. Thanks Andreas, Karsten, David and Thibaut for your input. +Emilien signature.asc Description: OpenPGP digital signature
Re: Maintainer scripts: execute command as another user: use sudo or su?
On Sat, 01 Mar 2014 22:55:20 +0100, Emilien Klein wrote: One minor challenge that I faced is that I couldn't get the commands to run using su. With the help of Karsten Hilbert I understood that the issue was that the user being a system user, she didn't have a shell (default shell for new system users is /bin/false). That's what Russ already mentioned in https://lists.debian.org/debian-mentors/2014/02/msg00499.html :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Beatles signature.asc Description: Digital signature
Re: Maintainer scripts: execute command as another user: use sudo or su?
On Wed, Feb 26, 2014 at 04:07:35PM +0100, Emilien Klein wrote: In the pre- and postinst scripts, a command has to be performed as that user (e.g. make a backup of the database). […] I am wondering what the best way is to fix this. I see 2 solutions: 1. Depend on sudo 2. Use su --command instead Beside what others already said: As you said it is run in preinst scripts you would need to pre-depend on sudo – and you would need to discuss this first on debian-devel@ as strongly recommend by debian-policy (§3.5 and §7.2). The outcome of this discussion would probably be that you should use su… su on the other hand is 'free' to use as it is provided by the essential login package, so no dependency is needed at all. Best regards David Kalnischkies signature.asc Description: Digital signature
Maintainer scripts: execute command as another user: use sudo or su?
Hi Mentors, TLDR: in order to execute a command as another user, should `sudo` or `su --command` be used? I'd like to get your opinion on how to best solve this issue: I've got a package [0] that uses dbconfig-common to manage its database. The database is owned by a specific user (not root). In the pre- and postinst scripts, a command has to be performed as that user (e.g. make a backup of the database). I've at first used sudo to perform that, and it worked fine until piuparts found an issue [1], since (as I hadn't realized) sudo is not part of the base system (installed on 76% of popcon-reporting machines [2]) I am wondering what the best way is to fix this. I see 2 solutions: 1. Depend on sudo 2. Use su --command instead First lines from the respective manpages: sudo, sudoedit - execute a command as another user su - change user ID or become superuser Following the Unix philosophy of using a collection of specialized small tools that do one thing best, when performing an action as another user it seems to be the correct thing to use a tool that execute a command as another user rather than one whose primary goal is change user ID or become superuser. But on the other hand, su is part of corutils (which is in the base install), so using su would remove the need of installing a new package for about 25% of our users. What are your thoughts on this? Thanks for getting a fellow Debian Maintainer out of his confusion! (and let's hope it doesn't turn into a vi vs. Emacs debate ;) ) +Emilien [0] http://pts.debian.net/pkg/gnuhealth [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739657 [2] Looking at popcon (obvious notice about [un]reliability of that data applies) data from 2014-02-24: - There are 167453 registered popcon users that sent information - corutils (package that amongst others, contains su) sports 167451 installations (99.998% of installs) [3] - sudo reports 127695 installations (76% of installs) [4] [3] http://qa.debian.org/popcon.php?package=sudo [4] http://qa.debian.org/popcon.php?package=coreutils -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canqxmqeaycazpww0s9t1wowszjjoajafzxrbryi10yugedv...@mail.gmail.com
Re: Maintainer scripts: execute command as another user: use sudo or su?
Le 26/02/2014 16:07, Emilien Klein a écrit : Hi Mentors, TLDR: in order to execute a command as another user, should `sudo` or `su --command` be used? I'd like to get your opinion on how to best solve this issue: I've got a package [0] that uses dbconfig-common to manage its database. The database is owned by a specific user (not root). Hi Emilien, I think you should use su. I am almost certain that sudo can be configured in such a way that would break your assumptions, whereas su can simply not be configured. Besides, as you noted yourself, using sudo would imply a completely unnecessary new dependency. su is the right using tool for assuming another personality and dropping privileges from root. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530e0ba1.9050...@free.fr
Re: Maintainer scripts: execute command as another user: use sudo or su?
Emilien Klein emil...@klein.st writes: TLDR: in order to execute a command as another user, should `sudo` or `su --command` be used? su. You don't want to depend on sudo to ensure that it's available, since package users may not want sudo installed on their systems. (I tend not to install it on servers myself, since I use Kerberos authentication and don't use any system that involves sending long-term keys to servers, such as sudo's default password model.) In addition, I recommend explicitly setting the shell to use when running commands with su (using the -s flag). Specialized users for running particular applications normally should not have a valid shell, and auditors will often require that they not have a valid shell. You don't want that sort of change (possibly required by local audit policies) to break the package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y50xv3l1@windlord.stanford.edu
