Re: User Profile handling in ancient release(s)

Hello Richard,

Am 21.09.2021 um 19:06 schrieb Richard Schoen <richard@xxxxxxxxxxxxxxxxx>:

What's the reason for switching profiles ?

Security. Access to objects not being allowed is enforced with that.

No other platform does this that I'm aware of.

This has been common practice in the Unix world ever since. When a network request is incoming, the main server — usually running as root — does a fork() for the established connection, and then drops privileges/switches user as soon as the user in question has successfully authenticated. This is most prevalent for telnet, ssh, ftp, IMAP and POP3 services, but not essentially limited to those.

In general a daemon job or web server/service generally runs under a specific server/daemon user profile and then all work is done under that user.

If the connected user is different from the current user running the application, newly created objects belong to the wrong user. The connected user might not even access "his" objects accessed in another way, with his authorizations for that reason. This is inconsistent for the user and might create additional work for the admin. Or the programmer, needing to change ownership for newly created objects.

Your recommendation works for other scenarios, though. Example is an SMTP server. The user must authenticate only to make sure he is authorized to send mail via that SMTP server. He would never need direct access to objects in the mail queue, though. So, it's perfectly okay for the SMTP server to start as root, bind to port 25 (must be done as root, because only root is allowed to bind to ports less than 1024) and afterwards drop privileges/switch to a static user profile for handling the queue. No user switching necessary.

The application I want to develop is to be thought as a highly specialized replacement for SQL access to PFs. I think of it to be more more or less a crude RPC interface for Spamassassin running on another host, to obtain *quick* access to it's Bayes- and AWL databases. My initial tests with SQL access work — with faster machinery. On my 150, SQL is just too CPU intensive. See https://github.com/PoC-dev/spamassassin-db2udb for details.

In fact, for my goal, I wouldn't need to switch users. But since I've grown up programming Linux, I've never even thought about *not* switching to the authenticated user. It's just one more line in the code and provides additional security, should an attacker find an exploitable bug to run arbitrary code on the host via my application. Better the attacker isn't able to do this as root.

However on IBMi you can certainly authenticate via the user profile check API, I would not be switching user profiles.
Unless you have a specific reason to do so.

See above. It depends.

:wq! PoC