[Debian-med-packaging] Bug#739657: gnuhealth-server: fails to install: gnuhealth-server.postinst: sudo: not found

[Andreas Tille]

Hi Emilien,

On Mon, Feb 24, 2014 at 10:04:22AM +0100, Emilien Klein wrote:
> >> I have heard the following argument from among Debian Devs:
> >>
> >> su is included with any installation (unless
> >> forcefully removed) while sudo is optional
> >
> > +1
> 
> Yes, that makes sense.
> Although for a package that requires more than 400Mb of dependencies
> (Tryton takes in parts of LibreOffice, etc.) one extra dependency on a
> package that is installed on 76% of machines (more details below)
> shouldn't be a deal breaker (and that's in line with what you both
> express in the next paragraph)

I'm aware that if you simply count the installed bytes the small sudo
package does close to no addition.  I'm rather concerned about the
principle to stick to the most simple way to approach a goal - if you
can do it with a standard tool of coreutils you simply should do it this
way.
 
> >> seems fairly succinct.
> >
> > As I said I personally regard the manpage as some unfortunate wording here.
> 
> I do think the manpages are rather correct:
> - su to switch user (default to root, can select other user), and a
> possibility to execute a command (but primary goal to be logged in as
> that user)

I think this "primary goal" is a quite personal interpretation of yours.
This would imply that the primary goal of a UNIX tool is to ignore its
possible options which is surely not the case. :-)  (Just assume that
the primary goal of `ls` is to be called as `ls` but some other program
is more dedicated to get some 'ls -l'-ish output.)

> - sudo to execute a command as another user (default to root, can
> select other user), with optional "features" such as limiting who can
> do what as another user, and logging who performed which command (none
> of these used in the current use-case)
> 
> > I learned `su` as "switch user" with the reasonable default to switch to
> > UID=0 (== root) but rather as a general means to switch to *any* user at
> > a given system and as the manpage perhaps less prominently but obviosly as
> > first option says it has an option
> >
> >        -c, --command COMMAND
> >            Specify a command that will be invoked by the shell
> >
> > My preference for su is that it is basic simple and you do not need to
> > install an extra package.  In contrast to su my perception of sudo was
> > always that by some reasonable confirguration you can give some fine
> > grained permissions to enable users becoming different roles by just
> > knowing their own password or a dedicated sudo password.
> 
> That is correct, although if you install the Desktop variant, as
> explained on the wiki [0] sudo will be installed and configured to
> allow the first user to execute commands as root using sudo.
> It's pretty much a colours/flavors question: I never use su, but
> always execute only those commands that need to be run by root using
> sudo.
> I see that a bit similar as the question about not allowing root to
> log in via ssh: it won't prevent any disaster just by itself, but
> could make it harder or delay it.

I think it is the other way around:  Any code you install without really
needing it might introduce some security whole.  So simply don't do it.

> > I personally
> > never used it to execute a command but only to become a different user
> > in a login shell and than do things.

Well, sorry, I need to redraw this statement: For sure I'm usin `sudo
cmd` very frequently.  What I really wanted to write is that I use it
only if I want to execute things as *root* and never if I *am* root and
want to execute it as somebody else.  For me sudo was invented to not
need to know the root password necessarily.  If you just are root you
do not need any other password ... and thus su is sufficient.

> > I might have the wrong gut feeling I would like you to dig for other
> > resources (like some look into /var/lib/dpkg/info or simply asking at
> > debian-mentors at lists.debian.org what people might think there).
> 
> Yes, I will do that.

Great.  I'm keen to hear this.

> Already just looking at popcon (obvious notice about [un]reliability
> of that data applies):
> - There are 167453 registered popcon users that sent information
> - corutils (package that amongst others, contains su) sports 167451
> installations (99.998% of installs) [1]
> - sudo reports 127695 installations (76% of installs) [2]

I would not use popcon here as an argument.  I'm sure that on the
majority of the existing machines sudo will be installed.  I just do not
see any reason to force users to install it if it is not used.
Considering that GNUHealth is running in critical environments like on
servers in hospitals you just want to minimise the intrusion vectors.
Not installing a not really needed package that might give you root
access is IMHO a vital advantage.
 
> > I think both solutions are OK if they are working but I personally would
> > definitely use the su-solution and would not spend a slight moment to
> > think about sudo.
> 
> I am also open to use su instead of sudo. That's even what I first
> did, but (for some reason I can't remember) didn't get the command to
> run succesfully using su, so I switched to sudo.

Ahh, may be you might be able to roll back and we might have a look at
this problem?

> Regardless of what comes out of the investigation and on the mentors
> ML, I will try to make it work using su, and figure if I can reproduce
> my issue with it.

:-)

> I look at this as a good learning moment.

As every day if you open your eyes in the morning :-)

    Andreas.

-- 
http://fam-tille.de