This is the mail archive of the
mailing list for the frysk project.
Re: Permission to task and proc
On Wed, Jul 19, 2006 at 11:55:36AM -0400, Sami Wagiaalla wrote:
> You should take a look at GuiProc.java. There is a function there called
> which does the filtering you described. There are a lot of data models
> using this function
> to do filtering. So you can search of references to isOwned.
Thanks for your information.
I could locate isOwned() in GuiProc.java.
> As for filtering at a lower level in the core. I think that a user
> should still be able
> to see a process that they do not own. This way they know to switch user or
> run as root to be able to debug that process. But if no one agrees then
> I am not
> against filtering in the core.
When I try to filter processes via getUID()/getGID(), I meet another
problem, that frysk-core still could not open /proc/<pid>/exe, when
frysk-core has the same GID with this process.
Here is the detailed information for your reference,
1. Run a simple testcase,
[qiyao@GreenHouse frysk-core]$ ./TestRunner frysk.proc.TestModify
lib.elf.ElfException: Could not open /proc/2095/exe for reading
There was 1 error:
1) testModify(frysk.proc.TestModify)lib.elf.ElfException: Could not
open /proc/2095/exe for reading
2. Check the information for process 2095.
[qiyao@GreenHouse frysk-core]$ cat /proc/2095/status Name:
State: S (sleeping)
Uid: 0 0 0 0
Gid: 500 42 500 42
3. Try to attach this process via GDB,
[qiyao@GreenHouse frysk-core]$ LANG="en" gdb -p 2095
GNU gdb Red Hat Linux (220.127.116.11-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
This GDB was configured as "i386-redhat-linux-gnu".
Attaching to process 2095
ptrace: Operation not permitted.
/home/qiyao/source/cvs/frysk-qiyao/frysk-core/2095: No such file or
4. I could find this process in Druid, and select observer for it.
Here are some questions or ideas to this problem, and appreciate
anyone here if you could clarify them for me. Thanks in advance!
a) How could frysk-core know "I" could control this process? In the
case I post above, frysk-core has the same GID with this process, but
frysk-core still could not open /proc/<pid>/exe.
b) Output from GDB tell us that current user could not attach to this
process, but I could find this process in Druid, and add some
observers to it. How could I verify that frysk could do some
operation to this process 2095? I doubt that fryks only add its pid
and executable name to Druid, and could not do some operations to this
process, such as attach to it.
IMO, the current uid/gid is equal to the uid/gid of the
process, does not mean frysk-core has the permission to read it, or
frysk-core could control this process. It is common that file could
not be red by the group user.
Is it a bug for isOwned() in GuiProc.java? Any comments on filtering