Re: /proc/pid/fd && anon_inode_fops

2013-09-03 Thread Pavel Machek
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 lo

Re: /proc/pid/fd && anon_inode_fops

2013-08-26 Thread Oleg Nesterov
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 me

Re: /proc/pid/fd && anon_inode_fops

2013-08-26 Thread Oleg Nesterov
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 r

Re: /proc/pid/fd && anon_inode_fops

2013-08-25 Thread Linus Torvalds
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 /proc/z

Re: /proc/pid/fd && anon_inode_fops

2013-08-25 Thread Oleg Nesterov
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 c

Re: /proc/pid/fd && anon_inode_fops

2013-08-25 Thread Andy Lutomirski
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 VFS,

Re: /proc/pid/fd && anon_inode_fops

2013-08-25 Thread Al Viro
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 i

Re: /proc/pid/fd && anon_inode_fops

2013-08-25 Thread Linus Torvalds
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 : /proc/se

Re: /proc/pid/fd && anon_inode_fops

2013-08-25 Thread Linus Torvalds
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 the

Re: /proc/pid/fd && anon_inode_fops

2013-08-25 Thread Oleg Nesterov
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 tr

Re: /proc/pid/fd && anon_inode_fops

2013-08-24 Thread Willy Tarreau
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

Re: /proc/pid/fd && anon_inode_fops

2013-08-24 Thread Al Viro
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 wh

Re: /proc/pid/fd && anon_inode_fops

2013-08-24 Thread Willy Tarreau
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

/proc/pid/fd && anon_inode_fops

2013-08-24 Thread Oleg Nesterov
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 thi