* open("foo", 3)
@ 2005-08-20 16:28 Miklos Szeredi
2005-08-20 17:30 ` Linus Torvalds
0 siblings, 1 reply; 3+ messages in thread
From: Miklos Szeredi @ 2005-08-20 16:28 UTC (permalink / raw)
To: torvalds, viro; +Cc: linux-kernel
Linus et Al,
Access mode of 3 is undocumented but it does do something halfway sane
on all linuxes (checked back to 2.0.X).
The open requires both read and write permission to succeed, but the
resulting file descriptor can neither be read nor written.
The responsible code in filp_open() is this:
namei_flags = flags;
if ((namei_flags+1) & O_ACCMODE)
namei_flags++;
/* ... */
error = open_namei(filename, namei_flags, mode, &nd);
if (!error)
return dentry_open(nd.dentry, nd.mnt, flags);
And in dentry_open():
f->f_mode = ((flags+1) & O_ACCMODE) | /* ... */
Note, that open_namei() is checking permissions, and dentry_open()
sets f->f_mode, but calculates it differently.
My question is: is this deliberate or accidental? Wouldn't it be more
logical to not require any permission to open such file? Or is there
some security concern with that?
Thanks,
Miklos
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: open("foo", 3)
2005-08-20 16:28 open("foo", 3) Miklos Szeredi
@ 2005-08-20 17:30 ` Linus Torvalds
2005-08-20 18:00 ` Steven Rostedt
0 siblings, 1 reply; 3+ messages in thread
From: Linus Torvalds @ 2005-08-20 17:30 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: viro, linux-kernel
On Sat, 20 Aug 2005, Miklos Szeredi wrote:
>
> My question is: is this deliberate or accidental? Wouldn't it be more
> logical to not require any permission to open such file? Or is there
> some security concern with that?
It's deliberate but historical. It's been a long time since I worked on
it, but it was meant for "special opens".
I _think_ it was used for things like "open block device without media
check" etc (we use O_NONBLOCK for that now), and it was used for directory
opens before we had O_DIRECTORY. (It's literally been years, so my
recollection may be bogus).
I don't think anything uses it any more, and it should probably be
deprecated rather than extended upon.
Linus
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: open("foo", 3)
2005-08-20 17:30 ` Linus Torvalds
@ 2005-08-20 18:00 ` Steven Rostedt
0 siblings, 0 replies; 3+ messages in thread
From: Steven Rostedt @ 2005-08-20 18:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, viro, Miklos Szeredi
On Sat, 2005-08-20 at 10:30 -0700, Linus Torvalds wrote:
>
> On Sat, 20 Aug 2005, Miklos Szeredi wrote:
> >
> > My question is: is this deliberate or accidental? Wouldn't it be more
> > logical to not require any permission to open such file? Or is there
> > some security concern with that?
>
> It's deliberate but historical. It's been a long time since I worked on
> it, but it was meant for "special opens".
>
> I _think_ it was used for things like "open block device without media
> check" etc (we use O_NONBLOCK for that now), and it was used for directory
> opens before we had O_DIRECTORY. (It's literally been years, so my
> recollection may be bogus).
>
> I don't think anything uses it any more, and it should probably be
> deprecated rather than extended upon.
It may also be dangerous, since I see several drivers using
if ((filp->f_flags & O_ACCMODE) != RD_ONLY) {
/* do something assuming we have write access */
...
}
Perhaps that access mode may not allow for getting to code like this,
but, since it's so old, you may have those that forget about the 3 mode,
and we lose the protection somewhere along the line.
It probably be better to not allow for it. Or maybe an audit of such
code needs to be replaced with:
if (filp->f_mode & FMODE_WRITE) {
...
}
Just my $0.02
-- Steve
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-08-20 18:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-20 16:28 open("foo", 3) Miklos Szeredi
2005-08-20 17:30 ` Linus Torvalds
2005-08-20 18:00 ` Steven Rostedt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®