RE: [MiNT] MiNTLib 0.52.3b

["Julian Reschke" <reschke@muenster.de>]

> From: Andreas Schwab [mailto:schwab@suse.de]
> Sent: Friday, August 06, 1999 3:24 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:
>
> |> > 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.

Now don't get silly. This is something you only do once, and you can also
put it into a library and call it 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.

My remark was based on my impression that you raised the supervisor mode
issue because of SECURELEVEL. It doesn't make sense outside that context :-)