From changelog: 

> - Remove pam_cap (bsc#1150522) since this PAM module is a bad idea, security
>   wise.

it seems that the removal is a decision which other distros haven't made.
There are use cases to use this pam module.

(In reply to ralf.koelmel@kit.edu from comment #2)
> it seems that the removal is a decision which other distros haven't made.
> There are use cases to use this pam module.

Can you elaborate on the use cases you have for it?

I suspect most other distros don't really review the PAM modules they ship so
it is not a surprise. In bug 1150522 you can find our reasoning for the
removal. Basically the module has a bad security design and mostly gives a
false sense of security. If the situation has changed by now (in the sense of
improved code quality) or if there is a major use case for it then we might
reconsider.

i have read the bug 1150522, but the main argument was, that the removal of the granted capabilities is not possible and this is not a problem on our case.
We use this module to grant some necessary capabilities for perf usage to distinct known users on compute nodes.
They can profile their experiments from the user context instead of doing this from the root account.
We know and trust this users but don't want to give root access to them.

(In reply to ralf.koelmel@kit.edu from comment #4)
> i have read the bug 1150522, but the main argument was, that the removal of the granted capabilities is not possible and this is not a problem on our case.

If I get it right the main concern was that it is unclean, because Admins can
easily create configurations that have weird security side effects. Another
aspect was the layer of fake isolation that this module is likely to provide.

> We use this module to grant some necessary capabilities for perf usage to distinct known users on compute nodes.
> They can profile their experiments from the user context instead of doing this from the root account.
> We know and trust this users but don't want to give root access to them.

Which capabilities are these exactly?

We can consider packaging the module again, as a separate sub-package that is
not installed by default but only by explicit user decision.

in capability.conf it is a line of each user of:
#  necessary for perf usage as unprivileged user
CAP_SYS_ADMIN,CAP_IPC_LOCK,CAP_SYSLOG <user>

in combination of the capabilities of perf
getcap /usr/bin/perf
/usr/bin/perf = cap_ipc_lock,cap_sys_admin,cap_syslog+ei


CAP_SYS_ADMIN is a huge right, but was necessary on Leap 15.3

a "default" base installation shouldn't install such a package, even if is not used.
But please don't forget the freedom of Linux, that Linux users should decide if they need such a functionality, even if it is less secure. 
openSUSE should not leave the way of a flexible and universal usable distribution (also in the future with the ALP development).

Would be great and lesser effort for me, if you can provide the package again !

Okay let's reopen the bug, I will have to discuss this in the team first to
come to a conclusion.

I agree regarding the freedom of choice, there should be a certain level of
quality to the software we ship, though, since we are also kind of vouching
for its quality and security by shipping signed RPMs containing it.

Your use case actually seems to be one where the use of the PAM module is
confusing at best, because CAP_SYS_ADMIN is equivalent to root, only it might
look differently on the surface when only looking at user accounts.

In the short term I could offer you to build an RPM with the pam_cap module
that you can download and install from the Open Build Service, the RPMs
signature will not be accepted by default by zypper though, you will have to
confirm that it's from an untrusted source when installing it.

maybe it would make sense to have some kind of "insecure" or "no recommended"
repository with a separate signing keys for such kind of software.

we have that, it's the open build service ;) I don't think we should officially add it back to the distribution, but have it as a package there. Users that need it can install it from there. The description of the package should link to both bugs and contain a warning that this is likely a bad idea

(In reply to jsegitz@suse.com from comment #9)
> we have that, it's the open build service ;) I don't think we should officially add it back to the distribution, but have it as a package there. Users that need it can install it from there. The description of the package should link to both bugs and contain a warning that this is likely a bad idea

I don't know if it is easily possible to activate this sub-package in the
devel project but *not* include it in Factory or other distribution projects.
Basically we would need a branched version of the package that includes this,
no?

What I meant regarding a separate repository was more the thought of a more
integrated and simple solution, like other distros have unstable repositories
we could gather such software in an insecure repository that can easily be
enabled for those that dare.

If I'm not mistaken then the OBS signing keys are tied to the projects i.e.
somebody wishing to e.g. add a package from the libcap devel project would
need to import and trust the Base:System project, which has quite some
repercussions.

Yes, that would be easiest way. I really don't want to have this as a package in the official builds, even if it's not included/installed by default. It's just one channel change away from being included in a product without us noticing.

AFAIK we don't have a mechanism for what you describe unfortunately.

What I would also find acceptable if the PAM module is restricted to limited capabilities. The half that basically means root should not be available. Then I would have far lesser issues with this being included again.

Well it seems there is no easy way to optionally include this module in the
mainline, and we don't want to fully include it again for the known reasons.

I will close this bug; if you're interested in installing this from an
unofficial project on the open build service I can give you more information
about this.