Messages in this thread | | | Subject | Re: FD_CLFORK or equivalent? | From | "James H. Cloos Jr." <> | Date | 06 May 1999 02:02:38 -0500 |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>> "Piete" == Piete Brooks <Piete.Brooks@cl.cam.ac.uk> writes:
[note pointing out error in my earlier post snipped]
Piete> It suggests to me that by using dup2, it should be possible to Piete> get a very high valued fd (much greater than the value of Piete> RLIMIT_NOFILE, and that setting RLIMIT_NOFILE to zero *should* Piete> close all files :-)) It says: RLIMIT_NOFILE /* max number of Piete> open files */ i.e. not (take off one as thge first fd is Piete> numbered zero) "the highest value of fd that can be opened" [ Piete> which is how I have always interpreted it ] but the *MAX Piete> NUMBER* of files (no mention of the fd values) that *CAN BE* Piete> open (rather than that open / dup / dup2 can return) -- snigger!
The relevant code in linux/fs/open.c concurs. get_unused_fd() includes this bit (at least in 2.2.7-ac1):
if (fd >= current->rlim[RLIMIT_NOFILE].rlim_cur) goto out;
At that point error is set to -EMFILE and out: will just return error;. EMFILE is of course too many open files.
So, if RLIMIT_NOFILE is 0, new files cannot be opened.
The question still remains. Should reducing either of:
current->rlim[RLIMIT_NOFILE].rlim_cur current->rlim[RLIMIT_NOFILE].rlim_max
close all fds above the new limit? Probably not for rlim_cur, but what about rlim_max? And even if not in the general case, what about the special case of setting both to zero?
An alternative, of course, whould be a syscall that returns an array of all the currently open fds.
Another would be a flag for all of the syscalls that deal w/ fds that says apply this to every open fd. That would allow an efficient way of setting the close on exec bit for each open fd.
In any case, ther *must* be an elegant, efficient, lean solution out there, hiding out there in someone's (sub)conscience.... :)
- -JimC - -- James H. Cloos, Jr. <http://www.jhcloos.com/cloos/public_key> 1024D/ED7DAEA6 <cloos@jhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
-----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.5 (GNU/Linux) Comment: For info see http://www.gnupg.org
iD8DBQE3MT6NmXqfF+19rqYRAuJNAKCJlwNNgKdiAnWjrLeZ/iPfoSHp7gCfZwDJ vVDWukLMMzwzrIo2BA33F+o= =EhpE -----END PGP SIGNATURE-----
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |