On Linux, I can get the current process's all open file descriptors by reading /proc/self/fd, but how I can get such info on FreeBSD?
Take a look at the procstat(8) utility, in particular the "-f" option.
It seems I can get such info by reading /dev/fd, see the manpage of fdescfs for more details.
https://www.freebsd.org/cgi/man.cgi?query=fdescfs&sektion=5&manpath=freebsd-release-ports
Related
Let's say I need to get the file descriptor of a file (or a directory) which has only execution (or search) permission.
The X/Open norm defines a O_SEARCH flag for the open() function. See http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
However, Linux doesn't. There are only 3 available flags (O_RDONLY, O_WRONLY and O_RDWR). See http://man7.org/linux/man-pages/man2/open.2.html
Why? And how can I get the fd of a directory with only search permission?
Thanks
It turns out Linux doesn't support, yet, this flag, as stated in W. Richard Stevens Stephen A. Rago's book "Advanced Programming in the UNIX Environment" which you can have a look at here Link to the book on google books
Actually, the flag is defined in POSIX, implemented in standard C library (which is in this case glibc, that's why you find it under man 3 open) but is not implemented in Linux kernel (thus not found under man 2 open).
EDIT 1 :
Since we use GNU under Linux, it includes specific headers for Linux to be able to make appropriate system calls that are feasable by Linux (in this case, it includes fcntl-linux.h in addition to fcntl.h).
EDIT 2 : Bug ticket
https://sourceware.org/bugzilla/show_bug.cgi?id=18228
Please, correct me if I'm wrong!
On Linux, you can obtain an fd for a directory that only has search permission using O_PATH. On other POSIX systems, you can fork a process and chdir to the directory; whenever you want to do openat relative to that directory, you can have the process perform open for you and send the fd to your main process (AF_UNIX and SCM_RIGHTS are a portable way of doing this).
Neither is strictly equivalent to O_SEARCH in the case where search permissions are revoked from the directory before access. POSIX guarantees that there will be no further permissions checks for an fd opened with O_SEARCH, but both O_PATH and chdir will check on every access.
If you look at open(3) (it looks like 3P in man pages, link) you should see that flag. I use ArchLinux updated at 2017-05-24.
EDIT 1: I edit the post to put a link to the screenshot so you can see the image, althoug I cannot use it in C.
If you want to look for into a directory, use opendir, readdir and the syscalls used for directory managing.
Why? And how can I get the fd of a directory with only search permission?
I don't know if that helps, but you can open read-only and look for the file you need, and then open that file with fopen in read-only mode.
My native language is not English. So I got problems when I read the document. In man page of close in FreeBSD: close - delete a file descriptor. And in Linux man page, close() closes a file descriptor, so that it no longer refers to any file. I'm wondering are they the same?
I need a program to list all the file that are accessed/opened by a process in Linux.
It should work like this,
o/p: The full path of the files that the process is accessing.
Don't want to use 'lsof' utility or any other utility.
Is there anyway to achieve this programmatically?
If you want just the files which are accessible thru opened file descriptors by process of pid 1234, list the /proc/1234/fd/ directory (most of the entries are symlinks). You'll also get additional details thru /proc/1234/fdinfo/
Try
ls -l /proc/self/fd/
to get an idea of what these files contain.
Programatically you could use readdir(3) after opendir(3) on these directories (and also readlink(2), at least for entries in /proc/1234/fd/ ....). See also proc(5)
Notice that /proc/ is Linux specific. Some other Unixes have it (e.g. Solaris), with very different contents, properties, semantics.
If you care also about files which have been opened and closed in the past by some process, it is much more difficult. See also inotify(7) and ptrace(2)...
To convert a file path to a "canonical" absolute fiile path, use realpath(3).
in Linux 2.6.27:
From "lsof" output I see a process holding open fd with a (deleted) file. The strange thing is that I can still see the file in the file system using "ls". Why is that?
thanks.
The file is not deleted as long as some process has the file open. When a file is closed, the kernel first checks the count of the number of process that have the file open. If this count has reached 0, the kernel then checks the link count; if it is 0, the file's contents are deleted.
To quote from man unlink:
If the name was the last link to a file but any processes still have
the file open the file will remain in existence until the last file
descriptor referring to it is closed.
When a file is deleted it would not been seen on the file system. However, it is quite possible another file with the same file name is created on the same location.
You can check the node number shown in lsof and ls -i to check whether they are really the same file.
Is it possible to make an executable look like a read-only file on Linux, such that opening the "file" for reading actually executes the file and makes its stdout available for reading as if it were data in the "file"? It should be openable by any program that knows how to open a file for reading, for example 'cat'.
Look at popen. Basically what you are describing is a pipe.
P.S. If you need language specific help, edit the question and add the language/environment you're working in and I'll try to provide more specifics.
Use FUSE
On unix-like OS's you can send the output of a program to a named pipe that is opened by another program. Look at the mkfifo command to create the named pipe. The named pipe works a lot like a file, with some limitations. For example, it is not seekable.
Seems like you could pipe the output of the program into whatever you are using to "read". The problem is if you want to open the executable in say emacs or vim or whatever, it's not a matter of the executable so much as the editor doesn't know any other way to interpret it.