Re: v2.1.106 (and earlier) /proc/<pid>/* is a mess...

Tigran Aivazian (tigran@sco.COM)
Sun, 14 Jun 1998 20:49:15 +0000 (GMT)


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