[PATCH] */*: Introduction USES=sudo

[kiwi]

Summary

*/*: Introduction USES=sudo

A new uses 'sudo' has been added to transperently depends of the
proper flavor of sudo 'default' or 'sssd' depending on the default
version set by the user.

If you prefere to use 'sssd' flavor of sudo, add the following
to your make.conf:

        DEFAULT_VERSIONS+=sudo=sssd

All sudo consummer ports has benn updated to USES=sudo

Approved by:    0mp
Approved by:    kevans
Sponsored by:   Klara, Inc.

Test Plan

Did a poudriere with DEFAULT_VERSIONS as default and sudo=sssd to test all consummer ports.

[0mp]

Thanks for posting this!

Mk/Uses/sudo.mk

19

env and lib were copied from another .mk file.

23

Let's drop the @ from here.

26

We can simplify all that into:

_SUDO_PORT= security/sudo
_SUDO_DEPENDS= sudo:${_SUDO_PORT}@${SUDO_DEFAULT}

32

35

Mk/bsd.default-versions.mk

192

missing comma

net-mgmt/librenms/Makefile

103

This port will probably need an update to CHANGES file informing the users that they need to switch to using DEFAULT_VERSIONS instead of OPTIONS to configure this port.

security/kf5-kdesu/Makefile

24–25

Missing build.

security/kf6-kdesu/Makefile

23–24

Missing build

sysutils/bhyvemgr/Makefile

4

Also, we don't really need to bump PORTREVISION in all those ports as there is nothing changing in the packages really.

18

I just noticed that we should try sorting sudo alphabetically into the USES list. It applies to all the ports me modify.

[mandree]

Please stop that. sudo may not even be my preferred tool to escalate privileges. I might prefer doas or su. Adding USES support for such a feature endorses it, and we'll see creeping changes to move the entire ports tree and user community towards SUDO.

That aside, if I can't tell people to stop the nonsense the commentary and texts need spell checking and options to use other tools instead of sudo.

[kiwi]

Addedd suggestions from 0mp

[kiwi]

In D52160#1192409, @mandree wrote:

Please stop that. sudo may not even be my preferred tool to escalate privileges. I might prefer doas or su. Adding USES support for such a feature endorses it, and we'll see creeping changes to move the entire ports tree and user community towards SUDO.

Well I do no try with this review to say "sudo is the best tool to escalate privileges", I just try to fix issues with sudo flavors that is used as a dependency in some ports.
You may not know but sudo can takes some informations using sssd, since it is not a good idea to pull per default sssd and all the dependencies used for some people (mostly corporate users).

I don't say this will fix sudo, but this will fix ports that depends of sudo.

Feel free to adapt other ports to use doas, so example, or mac_do.

That aside, if I can't tell people to stop the nonsense the commentary and texts need spell checking and options to use other tools instead of sudo.

Sorry about my english, not everybody have English as native tongue unfortunatly.

net-mgmt/librenms/Makefile

103

This should be done in the same commit ?

sysutils/bhyvemgr/Makefile

4

Idea is to push some check with poudriere, do you think it is a bad idea?

[arrowd]

Let me explain what's going on there.

Right now a bunch of ports has a hard runtime dependency on sudo in form of RUN_DEPENDS= sudo:security/sudo. But sudo actually has two flavors, so this change merely adds a new possible value for DEFAULT_VERSION and changes RUN_DEPENDS=sudo to USES=sudo to abstract from the actual selected version. This change does not make things any worse, it simply allows depending on sudo-sssd instead of sudo.

A couple of more points:

1. Once pkg gains proper provides/requires support we'll be able to remove this USES. With provides/requires a package may specify a dependency on the sudo program, which can then be fulfilled by any package that installs such a binary. More specifically, this would allow one to run pkg install sudo-sssd and will simple replace already installed sudo without the need to recompile consumers. The change proposed in this Diff is merely a workaround for not having provides/requires in pkg.
2. PORTREVISION bumps does not seem to be necessary. Nothing is changed wrt. dependencies in the default case.
3. Since this change touches bsd.default-versions.mk, maybe portmgr should be invoked too.

[arrowd]

security/kf5-kdesu/Makefile

24–25

Actually, sudo:build does not make sense. USES=sudo should not have arguments and only set RUN_DEPENDS.

We do have sort of provides/requires at the port level, so using BUILD_DEPENDS=sudo:security/sudo will work even if the default is sudo-sssd.

[arrowd]

security/kf5-kdesu/Makefile

24–25

Ah, no, it probably won't work in Poudriere, because it tries to install the package at the end of the build. This will pull in its runtime deps and create a conflict between sudo and sudo-sssd. So, disregard my previous comment, sorry for the noise.

[kiwi]

In D52160#1211528, @arrowd wrote:

Let me explain what's going on there.

Right now a bunch of ports has a hard runtime dependency on sudo in form of RUN_DEPENDS= sudo:security/sudo. But sudo actually has two flavors, so this change merely adds a new possible value for DEFAULT_VERSION and changes RUN_DEPENDS=sudo to USES=sudo to abstract from the actual selected version. This change does not make things any worse, it simply allows depending on sudo-sssd instead of sudo.

This is the idea indeed.

A couple of more points:

1. Once pkg gains proper provides/requires support we'll be able to remove this USES. With provides/requires a package may specify a dependency on the sudo program, which can then be fulfilled by any package that installs such a binary. More specifically, this would allow one to run pkg install sudo-sssd and will simple replace already installed sudo without the need to recompile consumers. The change proposed in this Diff is merely a workaround for not having provides/requires in pkg.

Yeah this is a workaround until pkg and the port infrastructure can add a runtime dependency : "I need this package as run dependency, what ever the flavor". This is far than perfect, but for a short terms this is a way to get the functionality working.

2. PORTREVISION bumps does not seem to be necessary. Nothing is changed wrt. dependencies in the default case.

Right noted. Will correct that.

3. Since this change touches bsd.default-versions.mk, maybe portmgr should be invoked too.

Sure, thank for the advice.

[mat]

Mk/Uses/sudo.mk

23

The _SUDO_FLAVOR variable is never used.

26

The _SUDO_DEFAULT variable is never set.

32

The variable _SUDO_DEPENDS is never set.

[kiwi]

• Added CHANGES informations
• Fix sudo.mk that was faulty
• Added sanity in sudo.mk

[kiwi]

The file sudo.mk has been remade.
Removed all PORTREVISION

[arrowd]

CHANGES

17

How about

... to allow depending on a different sudo flavor. Ports depending on sudo were updated to use an introduced USES.

[kiwi]

Update wording of CHANGES file.

[kiwi]

CHANGES

17

Thanks for your suggestion ! Adding it right now

[arrowd]

For what it's worth, this looks good to me.

[mat]

Another thing, only the build param is needed, the run parameter should not exist, and the RUN_DEPENDS should always be added.

Mk/Uses/sudo.mk

22–25

That is not needed, the build will fail anyway.

Also, if you do this, you have to keep it in sync with the sudo port, and it is bound to be forgotten at one point.

[0mp]

In D52160#1216301, @mat wrote:

Another thing, only the build param is needed, the run parameter should not exist, and the RUN_DEPENDS should always be added.

Current design:

• run dep: USES=sudo
• build dep: USES=sudo:build
• run & build dep: USES=sudo:build,run

What I think @mat suggests:

Current design:

• run dep: USES=sudo
• build dep: impossibe to express
• run & build dep: USES=sudo:build

I like the explicit nature of sudo:build,run. Having sudo:build mean RUN_DEPENDS + BUILD_DEPENDS is very confusing. It's true, however, that all the ports depending on sudo always need it for runtime. If that's a blocker for landing this, I'm fine with portmgr's decision.

Mk/Uses/sudo.mk

22–25

That's a fair point.

[mat]

The only reason a port will need sudo during build is to "detect" that it exists and work with it when being installed.
There will never be a port that only needs sudo during its build when it's not needed during its runtime.
A port must be buildable as a user, so sudo is of absolutely no use, also, ports are built as nobody, and nobody is not in sudoers.

The fact that sudo:build means build+run does not seems strange, It just means I require also require sudo during build.

I would rather there was no argument to USES=sudo, that it only added a RUN_DEPENDS, and that the two ports that seem to actually require it being there when they are built be patched so they don't need for it to be there during build to use it later.
Unless there is like a libsudo and some software links with that.

[kiwi]

In D52160#1216682, @mat wrote:

There will never be a port that only needs sudo during its build when it's not needed during its runtime.

Well it seems there is some ports that check if sudo is installed when building (well not building, but the configure part before building). That's why initially I have added build / run.

Anyway I am in neutral position about that and let @mat and my mentor @0mp deciding what should be the best for FreeBSD Community.

[0mp]

Let's follow mat's advice. Here's what I propose:

• Remove build and run options from USES=sudo.
• Introduce the following variables:

SUDO_FLAVOR?= ${SUDO_DEFAULT}
SUDO_PORT?= security/sudo
SUDO_DEPEND= ${PREFIX}/bin/sudo:${SUDO_PORT}@${SUDO_FLAVOR}

• Add ${SUDO_DEPEND} to ${BUILD_DEPENDS} where needed. We can patch those ports later to remove the build-time checks.
• Remove the check if SUDO_DEFAULT is sssd or default. This is not necessary, the ports framework will error out on its own.

[kiwi]

Update sudo.mk with suggested ideas of @mat and @0mp.
Checked with poudriere that the ideas make everything works (only on port touched by this reviews) uppon of sudo flavor used.

[0mp]

LGTM

I'd just rename SUDO_DEPEND to SUDO_DEPENDS to match the style used in other .mk files under Mk/Uses, but you can just do that right before the commit. No need to submit that style change to Phab again.

All in all, thanks a lot, Xavier, for addressing all the feedback!

[0mp]

net-mgmt/librenms/Makefile

103

oh, i missed this comment.

Yes. :)

[mat]

With the s/SUDO_DEPEND/SUDO_DEPENDS/ that Mateusz talked about, feel free to push it.