Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Jul 2014 15:31:04 -0400
From: Rich Felker <>
Subject: Re: unsure about the correctness of O_ACCMODE definition

On Tue, Jul 01, 2014 at 09:08:15PM +0200, wrote:
> 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
>  #else
>   ...
> ----
> (it makes open(...,O_NOACCESS) which succeeds, fully according to
> 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)

Using a value of 3 as the argument to open is a traditional Linux
extension for getting an fd that's usable only for ioctls. That's
reasonable. What's not reasonable or correct is using O_ACCMODE as a
way to get a 3.

> Then there is
> :

That document is from 1997. The current version of it is:

And as you can see, O_SEARCH and O_PATH are required to be included in
the bits for O_ACCMODE.

> 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).

Simply the current version of the standard is all you need to show
it's wrong.

> 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.

Because it's required by the standard.


Powered by blists - more mailing lists

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