[TUHS] v5 and v6 kernel is mode 777

[TUHS] v5 and v6 kernel is mode 777

[Noel Chiappa]

    > From: Mark Longridge

    > There's no reason for it to be mode 777 is there?

Not that I know of. Once UNIX has booted, it has no use for 'unix' (or
whatever file it booted from), and the boot loader doesn't even read the mode.

I think I habitually set mine to 644. (The 'execute' bits are, of course,
pointless...)

	Noel

[TUHS] v5 and v6 kernel is mode 777

[Dave Horsfall]

On Sun, 22 Feb 2015, Noel Chiappa wrote:

> > There's no reason for it to be mode 777 is there?
> 
> Not that I know of. Once UNIX has booted, it has no use for 'unix' (or 
> whatever file it booted from), and the boot loader doesn't even read the 
> mode.

Didn't "ps" try and read its symbol table?  I had fun days when I booted, 
say, "/unix.new", and "ps" wouldn't sodding work...

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] v5 and v6 kernel is mode 777

[Ed Carp]

Yes - I remember those days!

BTW, ever tried running /unix from a shell prompt? :)


On 02/22/2015 12:01 PM, Dave Horsfall wrote:
> On Sun, 22 Feb 2015, Noel Chiappa wrote:
> 
>>> There's no reason for it to be mode 777 is there?
>>
>> Not that I know of. Once UNIX has booted, it has no use for 'unix' (or 
>> whatever file it booted from), and the boot loader doesn't even read the 
>> mode.
> 
> Didn't "ps" try and read its symbol table?  I had fun days when I booted, 
> say, "/unix.new", and "ps" wouldn't sodding work...

[TUHS] v5 and v6 kernel is mode 777

[scj]

I do remember somebody sending an executable file to the voice synthesizer
once.  The results were so awesomely spectacular that the file was
promptly squirreled away an trotted out for visitors for years
afterwards...


> Yes - I remember those days!
>
> BTW, ever tried running /unix from a shell prompt? :)
>
>

[TUHS] v5 and v6 kernel is mode 777

[Mark Longridge]

Ron,

You are quite right. I tried to use 1bsd's ls in v5 for the columnar
output and there are bugs.

This is what it should look like:

ls -l /unix
-rwxr-xr-x  1 root    27066 Feb 22 14:34 unix

So it's now mode 755 and everything seems to work fine.

Mark

On 2/22/15, Ronald Natalie <ron at ronnatalie.com> wrote:
> Your ls is missing a set of perms (-rwxrwxrwx).
>
> No it should not be 777.    It needs to be readable because certain programs
> in user mode read the symbol table.
>
>
>

[TUHS] v5 and v6 kernel is mode 777

[Noel Chiappa]

    > From: Dave Horsfall <dave at horsfall.org>

    >> Once UNIX has booted, it has no use for 'unix' (or whatever file it
    >> booted from)

    > Didn't "ps" try and read its symbol table?

Sorry, meant 'UNIX the monolithic kernel'; yes, ps and siblings (e.g. iostat)
need to get the running system's symbol table.


    > I had fun days when I booted, say, "/unix.new", and "ps" wouldn't
    > sodding work...

Know that feeling! I added the following to one of the kernel data files:

    char *endsys &end;

and then in programs which grab the system's symbol table, I have an nlist()
entry:

  "_endsys",

with the follwing code:

  /* Check that the namelist applies to the current system.
   */

  checknms(symfile)
  char	*symfile;

  {	char	*chkloc, *chkval;

	if (nl[0].type == 0)
		cerror("No namelist\n");

	chkloc = nl[ENDSYS].value;
	chkval = rdloc(chkloc);

	if (chkval != nl[END].value) {
		cerror("Symbol table in %s doesn't match running system\n",
		       symfile);
		}
  }

on the theory that pretty much any change at all is going to result in a
change in the system's size (and thus the address of 'end').

Although in a split I/D system, this may not be true (you could change the
code, and have the data+BSS remain the same size); I should probably check
the location of 'etext' as well...

Anyway, a rebuilt system may result in the address of 'endsys' changing, and
thus the rdloc() won't return the contents of the running system's 'endsys',
but the chances of an essentially-random fetch being the same as the value of
'end' in /unix are pretty slim, I would say...

	Noel

[TUHS] v5 and v6 kernel is mode 777

[Dave Horsfall]

On Sun, 22 Feb 2015, Mark Longridge wrote:

> I just had it brought to my attention that the unix kernel is mode 777
> in Unix v5 and v6:
> 
> ls -l /unix
> -rwxrwx  1 root        27066 Mar 23  1975 /unix
> 
> There's no reason for it to be mode 777 is there? It seems rather 
> dangerous.

Those were happy days back then.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] v5 and v6 kernel is mode 777

[Ronald Natalie]

Your ls is missing a set of perms (-rwxrwxrwx).

No it should not be 777.    It needs to be readable because certain programs in user mode read the symbol table.

[TUHS] v5 and v6 kernel is mode 777

[Mark Longridge]

I just had it brought to my attention that the unix kernel is mode 777
in Unix v5 and v6:

ls -l /unix
-rwxrwx  1 root        27066 Mar 23  1975 /unix

There's no reason for it to be mode 777 is there? It seems rather dangerous.

In Unix v7 it defaults to mode 775 and in 32v it is 755. I figure it
setting it to mode 755 will work and so far it seems fine in v5.

Mark