[Coco] Telnet to your CoCo.. and invite 6 of your friends

[Boisy G. Pitre]

Bob/Aaron,

I checked the assembly for F$SUser and here it is:

FSUser   ldx   <D.Proc      get current process dsc ptr
         ldd   R$Y,u        get requested user number
         std   P$User,x     save new user # in process descriptor
         clrb               no error
         rts                and return

I checked the OS-9/68K version of F_SUser and here's what the docs say:

- Users with group ID zero may change their IDs to anything.
- A primary module owned by a group zero user may change its ID to anything.
- Any primary module may change its user ID to match the module’s owner.
All other attempts to change the user ID number return an EOS_PERMIT error.

There is no concept of a group number in OS-9/6809; nor do OS-9/6809 modules store the user id/group id in the module header, so none of the above apply.

I think the idea of making the F$SUser call available only to processes owned by the super user is a red herring. There are plenty of ways to wreak havoc under OS-9/6809 as a non-super user, and since all memory is writable, changing one byte in the kernel can bypass the check for super user completely.  Frankly, I wouldn't worry about changing F$SUser.
--
Boisy G. Pitre
http://www.tee-boy.com/

On Dec 1, 2009, at 5:21 PM, Bob Devries wrote:

> Should the new F$SUser call return an illegal service request error if an attempt is made by a user other than user 0?
> 
> I'm separated from my docs by some 1200 kilometers at this time, so I can't look that up, at least not easily.
> 
> Regards, Bob Devries
> 
> --
> Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
> 
> Edsger W.Dijkstra, 18 June 1975
> 
> ----- Original Message ----- From: "Aaron Wolfe" <aawolfe at gmail.com>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Wednesday, December 02, 2009 10:06 AM
> Subject: Re: [Coco] Telnet to your CoCo.. and invite 6 of your friends
> 
> 
> I'd be happy to try writing a replacement F$SUser that fails if the
> current userid > 0.  It's probably just a couple bytes of changes.
> 
> Would this break things?  I'm guessing the most compatible behavior
> would be not to return any errors, since the original always succeeds.
> 
> -Aaron
> 
> 
> On Tue, Dec 1, 2009 at 5:55 PM, Willard Goosey <goosey at virgo.sdc.org> wrote:
>> On Tue, Dec 01, 2009 at 03:36:50PM -0600, Boisy G. Pitre wrote:
>> 
>>> That's exactly what would happen... when the kernel scans for krnpX
>>> modules, it will call the os9 F$SSvc system call to install the
>>> system calls in that module; if any of those system calls reuse an
>>> existing system call number, then their address will overrwrite the
>>> address stored in the system call jump table in RAM.
>> 
>> Well, that's the definitive answer from the definitive master. :-)
>> 
>> That's really cool that a mechanism like that was already in place and
>> running at a time when most operating systems, even for mainframes and
>> minis, had completely statically linked kernels.
>> 
>>> It's a great way to extend the operating system.
>> 
>> Sounds really useful.
>> 
>> Willard
>> --
>> Willard Goosey goosey at sdc.org
>> Socorro, New Mexico, USA
>> I search my heart and find Cimmeria, land of Darkness and the Night.
>> -- R.E. Howard
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco