extreme newbie

[Dennis Lee Bieber]

This unnamed OS didn't allow granting execute access but not read access?

It barely had password protection (I suspect some students got
through four years without discovering how to supply a password or cross
user-id access). It did have a complex login scheme, however... One
needed to supply three pieces of information: User-ID, Account, Password
(while not used that way, I believe the concept was that the account was
the billing group, so a User-ID could be shared among different billing
groups).

CP/V on a Xerox Sigma-6.

Such lovely things allowed as: embedding non-printable control
characters into file names. Makes it real fun for someone to figure out
just where in a 10-character file name that console-beep is placed <G>
It also differentiated between an "update" vs a "scratch" file (read-n
then write, vs write-n then read -- separate read/write positions were
maintained).


--

 

[Grant Edwards]

Such lovely things allowed as: embedding non-printable control
characters into file names.

Don't most OSes allow that? Unix does, and IIRC VMS did as
well. In VMS there was a system call that let you change the
name shown by the equivalent of "ps". You could include
control characters in that string, and it was sort of fun to
change your name to little ASCII-art pictures. Well, it was
fun when you were a freshman.

Makes it real fun for someone to figure out just where in a
10-character file name that console-beep is placed <G>

Under Unix it's not all that hard to accidentally create files
like that. Sometimes you have to resort to blasting them away
by i-node number, or by moving the files you want to keep and
then nuking the directory.

 

[Mike Meyer]

Under Unix it's not all that hard to accidentally create files
like that. Sometimes you have to resort to blasting them away
by i-node number, or by moving the files you want to keep and
then nuking the directory.

A standard practice on our early Unix system at the university was to
issue the command '% touch "$HOME/*"; clear' on any terminals found
unattended. But we were a nasty bunch.

<mike

 

[Mike Meyer]

On Sat, 18 Jun 2005 15:00:02 +0200, Renato Ramonda wrote:
Hiding the source code does not make software more secure. Any bugs and
security holes will be there whether the software is distributed in source
code, object code, or something in between.

I'm going to be pedantic about this.

One definition of "more secure" is "has fewer security holes". With that
definition, hiding your source code doesn't make any difference.

Another definition of "more secure" is "has a higher cost to break
into." By that definition, hiding your source code *does* make your
software more secure. It's easier to find security holes by examining
source near "insecure" operations than it is by trial and error.

On the flip side, Thompson <URL: http://www.acm.org/classics/sep95/ >
has shown that distributing source is not a preventative for trojans.

<mike