Messages in this thread | | | Date | Sun, 14 Jun 1998 20:49:15 +0000 (GMT) | From | Tigran Aivazian <> | Subject | Re: v2.1.106 (and earlier) /proc/<pid>/* is a mess... |
| |
Hello guys,
We (Vadim and me) were debugging some stuff in fs/proc/base.c and discovered that the bug I mentioned earlier disappears if we remove the p->dumpable || (ino == PROC_PID_INO) check in proc_pid_fill_inode().
I understand why the ino == check should be removed but I am somewhat unclear why is dumpable flag relevant for the /proc/<pid>/* files and the connection (IRC) to Vadim was lost unfortunately so I couldn't ask him :)
Anyway, I thought you might like to know...
Regards, ------ Tigran A. Aivazian | http://www.sco.com/ Escalations Research Group | Email: tigran@sco.com Santa Cruz Operation Ltd |
On Sun, 14 Jun 1998, Vadim E. Kogan wrote:
> Tigran Aivazian wrote: > > > > Hello guys, > > > > There is a complete mess (I haven't figured out why yet) in the way > > inode->i_uid/inode->i_gid are handled for the files in /proc/<pid>/ if the > > process in question called setuid(2) or setgid(2), i.e. the > > proc_pid_fill_inode() is not called on them and thus (? I am not 100% sure > > that's the reason) the uid/gid are left to 0/0 (root/root). > Right, I just woke up with clear head, and found printk in > proc_pid_fill_inode. So I was on the way some time yesterday. > I also asked Alan, why is it p->euid and p->gid. Well, maybe somedoby > else can answer me that? > > > > > This is causing the famous "ps aux|grep login" and then ls -l /proc/<pid> > > bug mentioned by Vadim Kogan on #linux this afternoon. > afternoon? it was something like 2am!:) And yes, it's true for su too - > anything with setuid, but how else I can ask people on IRC to check > that? :) > > > > > > I changed the default for, say "status" to be "500" (tigran) and what I > > observe is that it is left to "tigran" which means someone forgot to fill > > the inode data, I guess? > > > > This also happens on 2.0.32 which means it's a global and serious problem. > I've seen reports that it happens on a) 2.0.34(not always?) b) 2.1.99 > (mine, clean) c) 2.1.105ac5 (mine, not clean, but that thing should be > the same) > > > > > Regards, > > ------ > > Tigran A. Aivazian | http://www.sco.com/ > > Escalations Research Group | Email: tigran@sco.com > > Santa Cruz Operation Ltd | > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.rutgers.edu > > Vadim >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |