unsure about the correctness of O_ACCMODE definition

unsure about the correctness of O_ACCMODE definition

[u-igbb]

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

Re: unsure about the correctness of O_ACCMODE definition

[Rich Felker]

On Tue, Jul 01, 2014 at 09:08:15PM +0200, u-igbb@aetey.se 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
>  # 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)

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
> http://pubs.opengroup.org/onlinepubs/7908799/xsh/fcntl.h.html :

That document is from 1997. The current version of it is:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html

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.

Rich

Re: unsure about the correctness of O_ACCMODE definition

[u-igbb]

On Tue, Jul 01, 2014 at 03:31:04PM -0400, Rich Felker wrote:
> The current version of it is:
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html

Thanks Rich,

It is exactly the information I was missing.
(Now reporting the bug to lilo)

Rune.