[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