Hi!
> > We are really stuck with the current semantics here - switching to
> > *BSD one would not only mean serious surgery on descriptor handling
> > (it's one of the wartier areas in *BSD VFS, in large part because
> > of magic-open-really-a-dup kludges they have to do), it would change
> > a
Hi!
We are really stuck with the current semantics here - switching to
*BSD one would not only mean serious surgery on descriptor handling
(it's one of the wartier areas in *BSD VFS, in large part because
of magic-open-really-a-dup kludges they have to do), it would change
a
On 08/26, Oleg Nesterov wrote:
>
> Not sure we really want this in this case but
>
> $ ./ls /proc/self/fd
> 0 1 2 3
>
> still works, I guess thanks to proc_fd_permission().
And btw. Whatever we do, shouldn't we change proc_fd_permission()?
/proc/self is actually /proc/tgid, this
On 08/25, Linus Torvalds wrote:
>
> On Sun, Aug 25, 2013 at 12:48 PM, Oleg Nesterov wrote:
> >
> > pid_revalidate() does inode->i_*id = GLOBAL_ROOT_*ID if task_dumpable()
> > fails, but it can fail simply because ->mm = NULL.
> >
> > This means that almost everything in /proc/zombie-pid/ becomes
On 08/25, Linus Torvalds wrote:
On Sun, Aug 25, 2013 at 12:48 PM, Oleg Nesterov o...@redhat.com wrote:
pid_revalidate() does inode-i_*id = GLOBAL_ROOT_*ID if task_dumpable()
fails, but it can fail simply because -mm = NULL.
This means that almost everything in /proc/zombie-pid/ becomes
On 08/26, Oleg Nesterov wrote:
Not sure we really want this in this case but
$ ./ls /proc/self/fd
0 1 2 3
still works, I guess thanks to proc_fd_permission().
And btw. Whatever we do, shouldn't we change proc_fd_permission()?
/proc/self is actually /proc/tgid, this means
On Sun, Aug 25, 2013 at 12:48 PM, Oleg Nesterov wrote:
>
> Or pid_revalidate(), but my concern is task_dumpable() logic.
>
> pid_revalidate() does inode->i_*id = GLOBAL_ROOT_*ID if task_dumpable()
> fails, but it can fail simply because ->mm = NULL.
>
> This means that almost everything in
Cough. I am going off-topic again, but I can't resist...
On 08/25, Linus Torvalds wrote:
>
> Look at the code that creates the fd stat information, for example.
> It's in tid_fd_revalidate(), and it really doesn't make much sense to
> use the task credentials for it.
Or pid_revalidate(), but my
On Sun, Aug 25, 2013 at 11:32 AM, Linus Torvalds
wrote:
> On Sat, Aug 24, 2013 at 10:23 PM, Al Viro wrote:
>>
>> We are really stuck with the current semantics here - switching to
>> *BSD one would not only mean serious surgery on descriptor handling
>> (it's one of the wartier areas in *BSD
On Sun, Aug 25, 2013 at 11:32:45AM -0700, Linus Torvalds wrote:
> On Sat, Aug 24, 2013 at 10:23 PM, Al Viro wrote:
> >
> > We are really stuck with the current semantics here - switching to
> > *BSD one would not only mean serious surgery on descriptor handling
> > (it's one of the wartier areas
On Sat, Aug 24, 2013 at 11:50 PM, Willy Tarreau wrote:
>
> Thanks for explaining Al, that really helps me understand. However
> there's still a difference between /proc/pid called from the process
> itself (=/proc/self) and called from other processes that seems to
> suit the situation :
On Sat, Aug 24, 2013 at 10:23 PM, Al Viro wrote:
>
> We are really stuck with the current semantics here - switching to
> *BSD one would not only mean serious surgery on descriptor handling
> (it's one of the wartier areas in *BSD VFS, in large part because
> of magic-open-really-a-dup kludges
Hi Willy,
On 08/24, Willy Tarreau wrote:
>
> On Sat, Aug 24, 2013 at 08:29:39PM +0200, Oleg Nesterov wrote:
> >
> > On 08/22, Willy Tarreau wrote:
> > >
> > > It's not only that, it also supports sockets and pipes that you can access
> > > via /proc/pid/fd and not via a real symlink which would
On Sun, Aug 25, 2013 at 06:23:17AM +0100, Al Viro wrote:
> On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
>
> > I doubt it. It seems to me that most such entries are implemented
> > for completeness while most valid uses only concern /proc/self/fd.
> > Maybe if we had an option so
On Sun, Aug 25, 2013 at 06:23:17AM +0100, Al Viro wrote:
On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
I doubt it. It seems to me that most such entries are implemented
for completeness while most valid uses only concern /proc/self/fd.
Maybe if we had an option so that
Hi Willy,
On 08/24, Willy Tarreau wrote:
On Sat, Aug 24, 2013 at 08:29:39PM +0200, Oleg Nesterov wrote:
On 08/22, Willy Tarreau wrote:
It's not only that, it also supports sockets and pipes that you can access
via /proc/pid/fd and not via a real symlink which would try to open eg
On Sat, Aug 24, 2013 at 10:23 PM, Al Viro v...@zeniv.linux.org.uk wrote:
We are really stuck with the current semantics here - switching to
*BSD one would not only mean serious surgery on descriptor handling
(it's one of the wartier areas in *BSD VFS, in large part because
of
On Sat, Aug 24, 2013 at 11:50 PM, Willy Tarreau w...@1wt.eu wrote:
Thanks for explaining Al, that really helps me understand. However
there's still a difference between /proc/pid called from the process
itself (=/proc/self) and called from other processes that seems to
suit the situation :
On Sun, Aug 25, 2013 at 11:32:45AM -0700, Linus Torvalds wrote:
On Sat, Aug 24, 2013 at 10:23 PM, Al Viro v...@zeniv.linux.org.uk wrote:
We are really stuck with the current semantics here - switching to
*BSD one would not only mean serious surgery on descriptor handling
(it's one of the
On Sun, Aug 25, 2013 at 11:32 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Sat, Aug 24, 2013 at 10:23 PM, Al Viro v...@zeniv.linux.org.uk wrote:
We are really stuck with the current semantics here - switching to
*BSD one would not only mean serious surgery on descriptor handling
Cough. I am going off-topic again, but I can't resist...
On 08/25, Linus Torvalds wrote:
Look at the code that creates the fd stat information, for example.
It's in tid_fd_revalidate(), and it really doesn't make much sense to
use the task credentials for it.
Or pid_revalidate(), but my
On Sun, Aug 25, 2013 at 12:48 PM, Oleg Nesterov o...@redhat.com wrote:
Or pid_revalidate(), but my concern is task_dumpable() logic.
pid_revalidate() does inode-i_*id = GLOBAL_ROOT_*ID if task_dumpable()
fails, but it can fail simply because -mm = NULL.
This means that almost everything in
On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
> I doubt it. It seems to me that most such entries are implemented
> for completeness while most valid uses only concern /proc/self/fd.
> Maybe if we had an option so that only /proc/self/fd would actually
> allow to access the fds
Hi Oleg,
On Sat, Aug 24, 2013 at 08:29:39PM +0200, Oleg Nesterov wrote:
> Sorry for off-topic, I am just curios.
>
> On 08/22, Willy Tarreau wrote:
> >
> > It's not only that, it also supports sockets and pipes that you can access
> > via /proc/pid/fd and not via a real symlink which would try
Sorry for off-topic, I am just curios.
On 08/22, Willy Tarreau wrote:
>
> It's not only that, it also supports sockets and pipes that you can access
> via /proc/pid/fd and not via a real symlink which would try to open eg
> "pipe:[23456]" instead of the real file.
But sock_no_open() disallows
Sorry for off-topic, I am just curios.
On 08/22, Willy Tarreau wrote:
It's not only that, it also supports sockets and pipes that you can access
via /proc/pid/fd and not via a real symlink which would try to open eg
pipe:[23456] instead of the real file.
But sock_no_open() disallows this,
Hi Oleg,
On Sat, Aug 24, 2013 at 08:29:39PM +0200, Oleg Nesterov wrote:
Sorry for off-topic, I am just curios.
On 08/22, Willy Tarreau wrote:
It's not only that, it also supports sockets and pipes that you can access
via /proc/pid/fd and not via a real symlink which would try to open eg
On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
I doubt it. It seems to me that most such entries are implemented
for completeness while most valid uses only concern /proc/self/fd.
Maybe if we had an option so that only /proc/self/fd would actually
allow to access the fds while
28 matches
Mail list logo
