linux-kernel - Re: RFC: Serial port DTR/RTS

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] [day] [month] [year] [list]

Message-ID: <0d3f89a8-66c6-2ae2-9cf3-6b2aff8e1f5e@netscape.net>
Date: Thu, 20 Nov 2025 05:31:27 -0800
From: Ned Ulbricht <nedu@...scape.net>
To: "H. Peter Anvin" <hpa@...or.com>, "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Greg KH <gregkh@...uxfoundation.org>, Theodore Ts'o <tytso@....edu>,
 Maarten Brock <Maarten.Brock@...ls.nl>,
 "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
 "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Serial port DTR/RTS - O_<something>

On 11/18/25 10:05, H. Peter Anvin wrote:

>> "(O_EXCL|O_NOFOLLOW)" provokes a thought...
>>
>> As essential context, fs/open.c build_open_flags() has:
>>
>> if (flags & O_CREAT) {
>>      op->intent |= LOOKUP_CREATE;
>>      if (flags & O_EXCL) {
>>          op->intent |= LOOKUP_EXCL;
>>          flags |= O_NOFOLLOW;
>>      }
>> }

[snip]

> I had missed the bit in the spec that says that O_CREAT|O_EXCL is required to
> imply O_NOFOLLOW (as Linux indeed does as seen above.)

Fwiw, earlier today I had an ultimately unsuccessful series of searches
using the Austin Group Issue tracker at:

https://austingroupbugs.net/view_all_bug_page.php

Searched (serially): "O_EXCL", "O_NOFOLLOW", "EEXIST", "ELOOP"; all with
no other filter refinements.  Then searched filtering by 'Section'
(multiple adjacent selections): 'open' .. 'openat'. In all results,
simply eyeball-scanned 'Summary' (w/o opening most).

Apparent upshot, unless I'm mistaken, is that the exact error return is
a trivial conflict with no appreciable impact on higher levels.

In roughly same vein, FreeBSD open(2) man page, specifically at
"[EMLINK]" and "STANDARDS", might possibly be stretched to read as
implicitly encouraging that assessment.

https://man.freebsd.org/cgi/man.cgi?query=open&manpath=FreeBSD+16.0-CURRENT

Alhough I don't have a FreeBSD box available to actually test
(O_CREAT|O_EXCL|O_NOFOLLOW) symlink behavior on that platform.  (Maybe
that combo's wired to detonate tnt nasal daemons? Dunno;-)

Unfortunately, this does prompt a close re-scrutinization of linux's
open(2) man page. Notwithstanding the damn spec, the linux man page
should precisely and accurately reflect the observed error return?

Ned