musl - unsure about the correctness of O

Follow @Openwall on Twitter for new release announcements and other news

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

Date: Tue, 1 Jul 2014 21:08:15 +0200
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: unsure about the correctness of O_ACCMODE definition

Hello,

I am troubleshooting lilo linked against musl. The combination does not
work which is not surprising:

It looks like there are two incompatible interpretations of O_ACCMODE
in musl and in lilo.

musl:

----
 #define O_ACCMODE (03|O_SEARCH)
----

lilo:

----
 #ifdef O_ACCMODE
 # define O_NOACCESS O_ACCMODE
 #else
  ...
----
(it makes open(...,O_NOACCESS) which succeeds, fully according to
opengroup.org: O_SEARCH in open(<non-dir>) leads to "undefined results"
but doesn't have to fail; then lilo tries ioctl() on the resulting fd,
which fails)

Then there is
http://pubs.opengroup.org/onlinepubs/7908799/xsh/fcntl.h.html :

----
 O_ACCMODE
    Mask for file access modes. 

 File access modes used for open() and fcntl():

 O_RDONLY
    Open for reading only. 
 O_RDWR
    Open for reading and writing. 
 O_WRONLY
    Open for writing only.

----

This document suggests somehow that O_ACCMODE is equivalent to
 (O_RDONLY|O_RDWR|O_WRONLY)

Actually it does not _have_ to be defined in such a way and might
e.g. include bits which are known to always be zero but that
would not look like a robust design.

I feel that the heuristics used in lilo is flawed but I lack firm
arguments to be able to say it is a bug (O_NOACCESS per se
seems to be obscure / non-standard / hardly documented).

I feel on the other side that the definition of O_ACCMODE in musl is
questionable and wonder whether anybody can comment on what and why
is right.

Thanks,
Rune

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.