Login 'postgres': Login class 'default': Setting priority failed: Permission denied

[Denis Shaposhnikov]

Hi,

after upgrading from 14.0 to 14.1-RELEASE-p1 I started to see log messages like

Jun 24 17:01:55 db su[1424]: Login 'postgres': Login class 'default': Setting priority failed: Permission denied

It's inside a jail. Does anybody know what does it mean and how to fix it?

Thanks.

[doug]

I believe this is a permissions issue. The file has root ownership and
permissions. The jail.conf setting need to be changed to do this. I can
give more specifics if I know what jail management you are using.

Doug

[Denis Shaposhnikov]

Hi,

On Mon, 24 Jun 2024, at 17:05, Denis Shaposhnikov wrote:
> after upgrading from 14.0 to 14.1-RELEASE-p1 I started to see log messages like
> Jun 24 17:01:55 db su[1424]: Login 'postgres': Login class 'default':
> Setting priority failed: Permission denied

More details. Inside jail I'm executing:

nice -n 5 doas id

and I see in /var/log/messages:

Jun 27 21:08:57 db doas[33054]: Login 'root': Login class 'root': Setting priority failed: Permission denied

So this is easy reproducible. The same command on the host system doesn't generate such log message.

[Paul Procacci]

So what exactly is the problem?

The error message is a legit error, that is, you cannot set a priority of a process from within the jail.

The error itself has always occurred.  We know this because you've never been able to set a priority from within the jail.
It's just newly logged.

~Paul

--

__________________

:(){ :|:& };:

[Denis Shaposhnikov]

Hi,

On Thu, 27 Jun 2024, at 21:29, Paul Procacci wrote:
>> nice -n 5 doas id

>> Jun 27 21:08:57 db doas[33054]: Login 'root': Login class 'root': Setting priority failed: Permission denied

> The error message is a legit error, that is, you cannot set a priority
> of a process from within the jail.

What do you mean? Just

nice -5 id

inside a jail doesn't generate the log message, but

nice -5 doas id

does. That was just an example. Actually Icinga runs a command, but before that it does `nice(5)`. That command uses doas and calls a script and that script uses su. I'm not setting a priority directly. In 14.0 all of that didn't generate log messages.

> It's just newly logged.

Aha! Thanks for the info. OK, how could I prevent it from logging it? I don't need it in the log every minute.

[Paul Procacci]

It *does* throw an error.  You just need to set the priority in the right direction:

# nice -n 5 id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)

# nice -n -5 id
nice: setpriority: Permission denied
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)

You have 3 options:

1) Remove the nice binary from the command that icinga is issuing.
2) Lower the priority of the command (higher value)
3) Redirect stderr to /dev/null.

[Denis Shaposhnikov]

Hi,

On Thu, 27 Jun 2024, at 21:57, Paul Procacci wrote:
> It *does* throw an error. You just need to set the priority in the
> right direction:
>
> # nice -n 5 id
> uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
>
> # nice -n -5 id
> nice: setpriority: Permission denied
> uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)

That's correct, but in my case nobody directly decreases the priority.

> 1) Remove the nice binary from the command that icinga is issuing.

Icinga does it inside it's daemon. And patching it just because this FreeBSD change doesn't look good.

> 3) Redirect stderr to /dev/null.

Log messages are from syslog, from /var/log/messages. Every minute syslog outputs such messages.

I found a workaround. I changed default class in /etc/login.conf from

priority=0

to

priority=inherit

So it looks like every jail must have `priority=inherit` in /etc/login.conf instead of default `priority=0`.

Thanks for the help.

[Olivier Certner]

Hi,

I almost missed your message. I'm the author of both the new login class error messages and the ability to specify 'inherit' for 'priority' (and also 'umask').

The "workaround" you found can be seen instead as the "real thing". First, let me explain what you are seeing. You never need any specific privilege to increase the nice value of some process (=decreasing priority), but you need some to decrease it (=increasing priority). That's why 'nice -n 5 id' works, and why 'nice -n -5 id' doesn't work (more precisely, it's the setpriority() call that doesn't) in a jail even as root, since root inside a jail isn't allowed to raise priority of processes/threads. What happens differently with 'nice -n 5 doas id' is that 'doas' does a full login, leveraging the login class mechanism. The 'default' class specifies 'priority=0', which means assigning a nice value of 0, which is not allowed as 'nice -n -5 id' was and for the same reason, given that 'doas' has nice value 5 at this point and you don't have privilege to decrease it. I think that, in general and in particular for actions potentially having an impact on security, it is always better to log failure, even if in your case there is no practical consequence to it.

I've been contemplating making 'priority=inherit' the default in the future, and your experience seems to back this direction.

Thanks and regards.

--
Olivier Certner

[Denis Shaposhnikov]

Hi,

On Fri, 28 Jun 2024, at 21:58, Olivier Certner wrote:
> I've been contemplating making 'priority=inherit' the default in the
> future, and your experience seems to back this direction.

Thank you, it explains everything.