linux-kernel - Re: [patch 2/2] ufd v1 - use unsequential O(1) fdmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 03 Jun 2007 12:43:23 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Davide Libenzi <davidel@...ilserver.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 2/2] ufd v1 - use unsequential O(1) fdmap

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Davide Libenzi wrote:
>> I agree with Ingo, no need for a second magic value.  Use the same value
>>  as FD_UNSEQ_ALLOC which will just mean this exact value should never be
>> used as a file descriptor.
> 
> I explained this in my answer to Ingo...

And if we have a new syscall we don't need any of that special dup2
behavior you describe.  I really don't think this should be added.  dup2
should just do what POSIX specifies, nothing more.  I would even suggest
to not allow to dup2() to a descriptor > RLIMIT_NOFILE unless it is
already allocated.  I.e., don't allow creating arbitrary high descriptors.

This behavior is completely consistent with the current implementation.
 No bad surprises.  In fact, it eliminates parts of the ABI
incompatibility I talked about.

> Random can be expensive. At the moment is FIFO. I'm missing though how 
> this can be a security flaw, when the legacy one is exactly predictable.

It's not an added security issue.  It would mean removing a possible
security the current file descriptor allocation has.

If randomizing each allocator is too expensive then randomize at the
very least the number of the first descriptor you give out.

> I can do a new syscall, no problem (I actually even slightly prefer). We 
> cannot break dup2() and F_DUPFD though, so we have to handle those too.

There is no requirement to duplicate everything since non-sequential
descriptors are a new feature.  Existing program will not be affected.
As said above, I think it is better if dup2() to a high descriptor which
does not exist is not allowed.  You have to be able to dup2() over an
existing one but that's it.

For F_DUPFD I also don't see justification for an extension to
non-sequential descriptors.  The concept of "greater than" makes not
much sense for non-sequential descriptors.  I think I would be more than
happy to restrict the specified lower bound to RLIMIT_NOFILE as it is now.

If latter this turns out to be a big limitation we can still extend the
dup2/fcntl functionality.  But removing functionality is harder.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGYxnb2ijCOnn/RHQRAkyoAJ4+L3W/aVYaQ/IG0HPm0tt5PKPcRACgoJYF
bChz20uicqD9tBbDtU1yruM=
=4vNd
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/