Re: [MiNT] MiNTLib 0.52.3b

[Andreas Schwab <schwab@suse.de>]

"Julian Reschke" <reschke@muenster.de> writes:

|> > From: Andreas Schwab [mailto:schwab@suse.de]
|> > Sent: Friday, August 06, 1999 2:28 PM
|> > To: reschke@muenster.de
|> > Cc: Martin-Eric Racine; Jo-Even.Skarstein@gjensidige.no;
|> > mint@fishpool.com
|> > Subject: Re: [MiNT] MiNTLib 0.52.3b
|> >
|> >
|> > "Julian Reschke" <reschke@muenster.de> writes:
|> >
|> > |> What kind of comment is this supposed to be? If you are able to write a
|> > |> umount.ttp which calls a system call like Dumount(), you sure
|> > can also write
|> > |> one which Dlock()s the drive and then clears the drive bit, correct?
|> >
|> > Modifying _drvbits requires going to supervisor mode.
|> 
|> a) we can allow to do it using XBIOS (Setexc for example),
|> 
|> b) in traditional Unix systems, you had to be root to unmount a filesystem
|> as well.

I don't talk about root, but about easy to program.  You can't just modify
_drvbits, you have to remember it's address, switch to supervisor mode
either with Supexec or Super.  That's a tad more that just calling
Dumount.

|> Removing a filesystem is in the same class like accessing it on the device
|> level, so it is not completely clear to me why one thing needs root access,
|> while the other doesn't...

Accessing a device inode follows the same access rules as any other inode
in the system, do I don't understand your remark.  Unmounting a filesystem
can compromise system security, so it needs to be made privileged.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg