>>>>> On Fri, 11 Mar 2005 03:58:33 -0800 (PST),
	"Kamal R. Prasad" <kamalpr@yahoo.com> said:

>> One of the reasons why it's done in userlevel instead of kernel is
>> that checkpointing has to store references to files as pathnames,
>> and usual UNIX kernel doesn't remember pathnames once the file is
>> opened.

> My patch doesn't remember pathnames. It constructs
> pathnames pased on struct proc fields (p_comm,
> p_pid..)

It seems you are talking the pathname of the command itself.
What I'm talking here are all files that the command is
using, via file descriptors, or mmap, etc.

>> - To implement process migration, a pathname is more
>>   portable than a file handle.

> The scheme which I have implemented allows the user to
> specify the program execution pts where he saves
> process state and restore them. The data and stack
> segment are quite vulnerable to corruption.

It seems you are missing point.
"Process migration" is:
1. do checkpointing.
2. move the checkpointed image to an other machine.
3. do checkpoint restaring on the other machine.
Due to the implementation of a file reference on Dragonfly,
process migration simply doesn't work.
That's a bad thing.

>> This is especially problematic at checkpoint restarting time.
>> That's why Dragonfly allows only wheel group to do checkpointing
>> by default.

> My patch ensures any and every unix process can
> checkpoint -without getting into any conflict.

It seems you are missing the security risk.
Due to the way how file references are recovered at checkpoint
restarting time on Dragonfly (I mean, what ckpt_fhtovp() in
sys/kern/kern_checkpoint.c on Dragonfly is doing), the checkpoint
feature cannot be used from usual user privilege.
Otherwise usual user can violate UNIX file access permission.

That's just bad.

>> Also, I'm not sure that exposing file handles to usual user is
>> always safe for all filesystems.  NetBSD and Dragonfly allow only
>> root to use getfh(2) systemcall. But it seems Dragonfly actually
>> exposes file handles for every user who can open the file, because
>> their coredump file includes file handles of the file descriptors
>> when the process dumps core.  (from DragonflyBSD's
>> sys/kern/imgact_elf.c:elf_putfiles())
>> Using a pathname doesn't have such security risks.

> Yeah -though I wouldn't want to comment on which
> implementation is better.

The one which doesn't have security risk is apparently better.
--
soda