Posing as a user on Mac OS X

On Windows, you can have a service that allows clients working in a user context to connect to it using sockets or pipes, and then impersonate a user to act on behalf of that user, for example, to access files that only the user has access to (or make sure other files are not available).

What is the equivalent way to accomplish this on Mac OS X (Linux is interesting too)? I would suggest that the set * uid functions will be used for this in some way?

But how do I authenticate the user I want to issue and set uid when the user connects to the socket?

In addition, set * uid functions affect the entire process, which makes them difficult to use in a multi-threaded daemon. Is there another widely used design pattern for this type of service on Mac OS X / Linux?

Edit: PMjordan's answer will apparently take care of the * uid problem set for the process only and the question How can I transfer user credentials through a Unix domain socket in Mac OS X? seems to be taking care of the real authentication problem using unix domain sockets instead of regular sockets.

+4
source share
2 answers

For OS X Features: Have you looked at the Authentication, Authorization, and Permissions Guide for Mac OS X?

Typically, on UNIX-like operating systems, processes usually belong to one specific user, and what they are allowed to do is largely determined by this. There are some exceptions to this, but as a rule, the idea, as a rule, is to do this for the granularity of each process. On the plus side, starting new processes is very simple - see the fork() function .

Thus, a typical way for a daemon (for example, sshd) to impersonate other users is to start the main process with root privileges. Then accept the incoming connections and pass them to the child processes fork() ed, which, as you say, immediately give privileges with set * uid. There are various communication channels between processes, such as channels that you can configure if child processes must interact with the parent process. Obviously, the less code that runs as root, the better, from a security point of view, so you want child processes to be autonomous.

If you need users who really provide their username and password, things get a little more complicated; you can look at the source code for the su and sudo utilities and read the platform documentation for the authentication API.

+2
source

from Technical Note TN2083 - Apple Developer

In some cases, it is useful to impersonate the user, at least until checking permissions performed by the BSD kernel subsystem. A single-threaded daemon can do this with seteuid and setegid. They set the effective identifier of the user and the process group as a whole. This will cause problems if your daemon uses multiple threads to process requests from different users. In this case, you can set the effective user ID and thread group using pthread_setugid_np. This was introduced in Mac OS X 10.4.

+1
source

Source: https://habr.com/ru/post/1399424/


All Articles