I have a device driver module which does a register_chardev(). In the driver open() function I wish to be able to determine the pid or pgid of the process which is attempting to open the device node. Is this possible? Does anyone have any ideas of where to begin?
I am assuming this should somewhat secure my device node to only allow my applications to use it, since you cannot migrate a process to a new process group unless they are in the same session.
The kernel isn't the right place to make this kind of policy decision - the correct place to set the permissions on who can open the device node is by setting the usual ownership and permissions on the device node file in the filesystem.
If you really have your heart set on it, current->pid is the PID, current->tgid is the thread group id and current->group_leader->pid is the PGID.
Related
I am writing a service/module in Go for a bigger system and I'm having trouble with permissions on macOS. I am hoping anyone here has any experience with this.
This module is using network interfaces in macOS (read+write), and therefore needs admin/root permissions. The module is also in the form of a process which will communicate with parent process through stdio. Since it needs root permissions, I have tried wrapping it in AppleScript: do shell script [...] with administrator privileges, but osascripts does not return the output in real time, instead it returns the stdio output when process has exited. I need the stdio output in real-time, and it is annoying to write the password every time the module is started.
So that leaves me with the question of how I can request permissions for network control in Go. Like the popup you see on some programs "wants to use your microphone", only with network permissions. Is this possible?
If not, how can I solve this issue of needing root permission for a real-time module in macOS?
I found a viable solution; launching the script with sudo -S , and asking the user for root password through my own GUI service. As long as the root password isn't stored anywhere, it should be fine security-wise.
I am using a utility called Wireless Network Watcher https://www.nirsoft.net/utils/wireless_network_watcher.html on a -windows 10 machine- that captures the devices connected to my network and export these items to a csv file periodiacally.
The app also offers some command-line options to start the app in the background and scan the network and export the items to a file.
But when I get disconnected from my network (and that happens a lot), the scanning process of the app stops and I need to correct this on each disconnect.
I chose to do this by creating a scheduled task that kills the app when disconnection happens and another one to restart it when I get connected again.
But when I do this, I lose the already recorded items on the already running instance of the app (Like devices that were connected and now are not), so I want to use the command-line option to export the items to a file before killing the app.
C:\WNetWatcher.exe /scomma C:\log.csv
So my question is: Is it doable to pass some parameters (/scomma in my example) to an already running instance of an application, and not starting a new one?
Here are the command Line Options available within the app:
I need to gather a list of all mounted "mount points" that the local file system has access to.
This includes:
Any ordinarily mounted volume under /Volumes.
Any NFS volume that's currently mounted under /net.
Any local or remote file system mounted with the "mount" command or auto-mounted somehow.
But I need to avoid accessing any file systems that can be auto-mounted but are currently not mounted. I.e, I do not want to cause any auto-amounting.
My current method is as follows:
Call FSGetVolumeInfo() in a loop to gather all known volumes. This will give me all local drives under /Volumes as well as /net, /home, and NFS mounts under /net.
Call FSGetVolumeParms() to get each volume's "device ID" (this turns out to be the mount path for network volumes).
If the ID is a POSIX path (i.e. it's starting with "/"), I use readdir() on its path's parent to check whether the parent dir contains actually the mount point item (e.g. if ID is /net/MyNetShare, then I readdir /net). If it's not available, I assume this is a auto-mount point with a yet-unmounted volume and therefore exclude it from my list of mounted volumes.
Lastly, if the volume appears mounted, I check if it contains any items. If it does, I add it to my list.
Step 3 is necessary to see whether the path is actually mounted. If I'd instead call lstat() on the full path, it would attempt to automount the file system, which I need to avoid.
Now, even though the above works most of the time, there are still some issues:
The mix of calls to the BSD and Carbon APIs, along with special casing the "device ID" value, is rather unclean.
The FSGetVolumeInfo() call gives me mount points such as "/net" and "/home" even though these do not seem to be actual mount points - the mount points would rather appear inside these. For example, if I'd mount a NFS share at "/net/MyNFSVolume", I'd gather both a "/net" point and a "/net/MyNFSVolume", but the "/net" point is no actual volume.
Worst of all, sometimes the above process still causes active attempts to contact the off-line server, leading to long timeouts.
So, who can show me a better way to find all the actually mounted volumes?
By using the BSD level function getattrlist(), asking for the ATTR_DIR_MOUNTSTATUS attribute, one can test the DIR_MNTSTATUS_TRIGGER flag.
This flag seems to be only set when an automounted share point is currently unreachable. The status of this flag appears to be directly related to the mount status maintained by the automountd daemon that manages re-mounting such mount points: As long as automountd reports that a mount point isn't available, due to the server not responding, the "trigger" flag is set.
Note, however, that this status is not immediately set once a network share becomes inaccessible. Consider this scenario:
The file /etc/auto_master has this line added at the end:
/- auto_mymounts
The file /etc/auto_mymounts has the following content:
/mymounts/MYSERVER1 -nfs,soft,bg,intr,net myserver1:/
This means that there will be a auto-mounting directory at /mymounts/MYSERVER1, giving access to the root of myserver1's exported NFS share.
Let's assume the server is initially reachable. Then we can browse the directory at /mymounts/MYSERVER1, and the DIR_MNTSTATUS_TRIGGER flag will be cleared.
Next, let's make the server become unreachable by simply killing the network connection (such as removing the ethernet cable to turning off Wi-Fi). At this point, when trying to access /mymounts/MYSERVER1 again, we'll get delays and timeouts, and we might even get seemingly valid results such as non-empty directory listings despite the unavailable server. The DIR_MNTSTATUS_TRIGGER flag will remain cleared at this point.
Now put the computer to sleep and wake it up again. At this point, automountd tries to reconnect all auto-mounted volumes again. It will notice that the server is offline and put the mount point into "trigger" state. Now the DIR_MNTSTATUS_TRIGGER flag will be set as desired.
So, while this trigger flag is not the perfect indicator to tell when the remote server is unreachable, it's good enough to tell when the server has become offline for a longer time, as it's usually happening when moving the client computer between different networks, such as between work and home, with the computer being put to sleep in between, thus causing the automountd daemon to detect the reachability of the NFS server.
I'm trying to get a process name from its pid. User is running as Administrator, UAC enabled, not elevated.
Some system processes, like services.exe, have their security set up in such way that OpenProcess(PROCESS_QUERY_INFORMATION ... fails with ERROR_ACCESS_DENIED. Same result with PROCESS_QUERY_LIMITED_INFORMATION access right. However, I can see that Process Explorer can at least list all these processes, along with their pid and file name (when running as non-elevated Administrator).
My question is, how can I do the same (get file name from pid), given that non-elevated administrator cannot follow the usual route of OpenProcess() + GetProcessImageFileName()?
Have you tried Process32First() and Process32Next() with a handle retrieved by CreateToolhelp32Snapshot()? It doesn't give you the full path but should at least let you get the file name.
Have you tried PROCESS_QUERY_LIMITED_INFORMATION instead? It requests a lower level of access that can provide at least the name of the executable. It allows you to call QueryFullProcessImageName which provides the information you're looking for
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684919(v=vs.85).aspx
You can't open system processes (more precisely, processes running under another account - in this case user SYSTEM) without SE_DEBUG privilege enabled for your process.
If you are running as admin, you can easily set the privilege:
http://support.microsoft.com/kb/131065/en-us
I am developing an utility application which logs other apps' file system activities. Therefore I am looking for a way to receive file system change notifications including the file paths as well as the corresponding PIDs.
According to my state of knowledge the only way to do this is to listen at "/dev/fsevents" using root privileges. Is there another option to track those file system changes without running a root privileged process?
Thanks in advance!
regards,
Tobias
No. You need to use /dev/fsevents or dtrace or something, all of which require root privilege.
As you know, the public FSEvents api doesn't give you fine grained info as you want.
But this is as it should be. When you ask "is this possible without root privilege?", you should ask yourself "do you want others to do this without root privilege on my machine?"
Then you know this is clearly wrong if it's possible without root privilege: you shouldn't be able to know, without root privilege, which file is accessed by a privileged process.