[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mtab (was: Re: path+file_name from port or process info?
From: |
David Walter |
Subject: |
Re: mtab (was: Re: path+file_name from port or process info? |
Date: |
Thu, 25 Jul 2002 15:03:40 -0400 |
User-agent: |
Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-unknown-gnu0.2) |
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> Translators should check if they run suid or sgid, if not, they
> should check if $MTABSERVERS is set and use that. If it is not set,
Did you mean for this to be plural? If so how would an translator
decide which of any $MTABSERVERS to insert into? Or would you have the
translator insert into _all_ of them?
> or they run suid/sgid, and they run as root, they should use
> _PATH_MOUNTED if it exists. If they run as normal user, they should
> use $HOME/.mtab (or something similar) if it exists. They should do
> whatever is necessary to register themselves with this filesystem (I
> think writing a single line with the path is the thing to do -- the
> rest can be derived by mtab).
I prefer the translator knows when to insert itself idea to the
fsysopts plan.
Let's see when should a translator insert itself into / notify mtab?
and vice versa.
1. a system file system that is auto mounted
a) a filesystem declared in /etc/fstab
b) a passive translator for a filesystem which is sitting on a node
with suid,sgid set or root ownership.
c) same as b, but started with mount or settrans by a user who is
the same.
2. a file system that shouldn't be included might be:
a) an experimental filesystem
b) one that is hidden from users for some reason
> df should check _PATH_MOUNTED and $HOME/.mtab (or something similar) and
> concatenate the output.
Right, this makes sense.
> The user should be able to override (and change at runtime) the path that
> the translator registers with mtab by setting --mtab PATH. It should be
> able to suppress registration (unregister at runtime) with --no-mtab.
You've lost me on part a of this.
Why should the user want to change the path that mtab registers? Is
this to address the mount point moved problem you noted later?
> I think so far we agree (as soon as you forget about the mount thing :)
Done(forgotten). I only mentioned that as it seemed where we are left
if we depend on the user to _do the right thing_ (tm).
> Now, what about the following questions:
>
> * Can a translator determine the path to be registered with mtab
> automatically?
>
> * If yes, which translators should do this by default, unless --no-mtab is
> given.
>
> I think the _hurd_canonicalize_dirname_internal function is worth trying
> out. It might just be what we want in the normal case, which will certainly
> be 99% of the cases. The rest can use --mtab explicitely. Also, if you
> move the filesystem, you need to kick off a change to mtab manually[2].
Hmm. I have tried this. In the simple case of
file_t f;
f=file_name_lookup(...);
_hurd_canonicalize_dirname_internal(f,0,0);
I get the right thing to happen. But where is the node(port) for the
underlying filesystem?
the current iteration of the mtab translator is using trivfs and I
have so far (unsuccessfully) tried the following:
attempt using the following from trivfs_peropen_create_hook()
open_hook (struct trivfs_peropen *peropen)
peropen->cntl->{file_id,filesys_id,underlying}.
None of these seems to be correct.
Then I tried the following:
error_t (*trivfs_protid_create_hook) (struct trivfs_protid *) =
local_protid_create_hook;
where the following looked promising.
realnode = protid->realnode;
This fails to be the correct item also, apparently.
So I began to track backward in the process.
It looks like settrans sets the active translator using the
fshelp_start_translator function.
this uses a callback defined in settrans (this is for my information,
you are probably more familiar with this process, sorry for the boring
details) open_node.
open_node sets the node variable (file_t node) based on
file_name_lookup, which is then passed to file_set_translator.
>From here I get lost as the following look like the function
file_set_translator but don't seem to match in behaviour. Perhaps
I've got mismatched headers or something, but a grep-find of libc hurd
and gnumach sources yields several file_set_translators.
Unfortunately for me I can't find where the implementation of one
matches, the mig definitions or fs.h.
>From fs.h
__file_set_translator
(
file_t file,
int passive_flags,
int active_flags,
int oldtrans_flags,
data_t passive,
mach_msg_type_number_t passiveCnt,
mach_port_t active,
mach_msg_type_name_t activePoly
);
>From libdiskfs:
/* Implement file_set_translator as described in <hurd/fs.defs>. */
kern_return_t
diskfs_S_file_set_translator (
struct protid *cred,
int passive_flags,
int active_flags,
int killtrans_flags,
char *passive,
size_t passivelen,
fsys_t active)
So where I am stymied is the use of struct protid*cred, where I had
expected to find a file_t file.
I was hoping that I could find some underlying call that carried the
file_t that the mtab translator can copy from, but I must be missing
the mark on that.
> [2] Unless you go for a very complicated and somewhat expensive solution and
> request dir notification messages on all dir nodes that are in your path, and
> then act on rename operations properly. Which is, again, not guaranteed to
> work, but would be the honest attempt approach at doing the right thing.
> However, I think this is overkill, for the following reason: The
> things you want in mtab are the permanent filesystems like /, /mnt, /cdrom,
> etc, which usually are not moving around a lot. The more dynamic filesystems
> should not be registered with mtab anyway.
Right, this is a potential problem but the ramifications of this
aren't clear until I can see that the trivfs_* translator actually has
access to the underlying node in some way?
--
Hurd References:
http://www.gnu.org/software/hurd/
http://www.freesoftware.fsf.org/thug/gnumach_hardware.html
http://ftp.walfield.org/pub/people/neal/papers/hurd-installation-guide/english/hurd-install-guide.html
http://www.vmlinux.org/twiki/bin/view/Hurd/WebHome
- path+file_name from port or process info?, David Walter,,,, 2002/07/22
- mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/22
- Re: mtab (was: Re: path+file_name from port or process info?, David Walter, 2002/07/22
- Re: mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/23
- Re: mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/23
- Re: mtab (was: Re: path+file_name from port or process info?,
David Walter <=
- Re: mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/25
- Re: mtab (was: Re: path+file_name from port or process info?, Alfred M. Szmidt, 2002/07/25
- Re: mtab (was: Re: path+file_name from port or process info?, David Walter, 2002/07/25
- Re: mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/25