lkml.org 
[lkml]   [1999]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: FD_CLFORK or equivalent?
From
Date
-----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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:1.485 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site