Thanksgiving Day Remedial

Rush transcript.

Get It Try It

Good morning. Are we all here now? OK, let's start right up. Are they going to bring coffee into us at ten? Ten-fifteen? OK.

Anyway. Some of you I recognise. I don't want to say how much you've changed. Don't you either! Steve was still with us back then, although many of us must have known what was really going on. Scott Forstall was still around, as I remember. What's he doing today? Broadway shows? Whatever.

Anyway. As you should know, attendance at this lecture is not a requirement, but passing the subsequent exam is. You won't be expected to know anything about Reese or Jennifer, but you will be expected to know a few things about bits and bytes.

That's 'b-Y-t-e-s' and not 'b-I-t-e-s' of course.

Anyway. And the reason we're going to delve into the arcane world of information technology? You'll see in a while.

Yes, you're mostly involved with the overall design of human interfaces, and so you're normally not expected to have any knowledge of the gory details. By the bye, were any of you involved in the decision to create the concept of the 'locked file'? Or was that just the programmers trying to solve your puzzle?

We're going to look very briefly at secondary storage. What is secondary storage, you might ask. Obviously there's a primary storage too, as otherwise there wouldn't be a secondary. Primary storage is computer memory. RAM. Random Access Memory. That name seems to have lost its meaning over the years. It's all those chips they put into a Mac. You know, you can usually buy additional RAM chips to very agreeable prices. Well, to prices anyway. That's primary storage. And, back in the days of IBM's monster mainframes, primary storage was accomplished with ferrite cores, and those cores could keep their values for a bit even if the electrical current was cut off.



Not so much with today's RAM chips. Thus the even more pressing need for reliable secondary storage. Are any of you familiar with John von Neumann? You should be. No, really. John von Neumann is the one who gave his name to the concept of 'Von Neumann Architecture'. He basically established how computers had to work. All those nice things like register shifts and rotations go into the broader definition today. So does secondary storage.

Secondary storage is persistent memory. As opposed to volatile memory, which is RAM today. Persistent memory - secondary storage - is memory that doesn't need a power supply to retain its values. Secondary storage is where computers save stuff they want to get back to.

Clear as mud?

The first Macs had floppies. You've heard of floppies, right? Yes, it's a hardware matter, and you're not supposed to have any focus on hardware at all, but bear with me. You've heard of floppies, right?

They got smaller and more efficient as time went on. And then we got the 'hard drive'. And a lot of Macs still have hard drives. Although today we're seeing a total transition to the solid state drive instead. That's what we have in the latest Macs, the latest iPads, iPhones, and so forth. Solid state drives.

Old hard drives were actually a stack of platters. Capable of recording things magnetically. A precise location was defined by its head, its cylinder, and its sector. Today with solid state things are different. And that all happens at driver level anyway.

The takeaway here is that our filesystems must have, and do have, a way of addressing storage locations on a higher level. We might call them logical allocation units, or cluster numbers, or something like that. For every byte saved in a filesystem, that filesystem must know how to locate it, given a type of logical number. In the old world of the Mac, that unit was called the Catalogue Node ID or CNID for short. In the world of Unix, that unit is called the inode. Note the use, in both cases, of the concept 'node'.

Storage devices can be either logical or physical or both, just to confuse matters even more. Yes, it's coffee at ten fifteen. Not until then!

Now looking at your Mac filesystems. Do any of you own a Mac? Show of hands? Oh really? What do you normally use? iPads? Show of hands? OK. And now iPhones? Yes of course. How about Apple watches? Yes, that was a joke. You're permitted to laugh.

OK. All of you should somehow acquire access to a Mac. You won't pass the exam otherwise. OK, I'll continue anyway.

Your factory default Mac has a number of logical and physical storage devices, also called 'volumes'. You might be aware that the Mac already has a directory - folder - under root called 'Volumes'. That's where new volumes are mounted when the system recognises them. For example, if you double-click a DMG file. Then it will appear there once it's mounted.

So that mount becomes a new volume, so to speak. And you already have a volume at root. Each volume has a unique file system ID. The file system ID can be expressed as a sixteen-digit number. The number's hex, sorry!

You have another volume at /dev. Finder won't recognise /dev. We'll get to that later. Then you have additional volumes at /home and /net. And so forth.

The key to all these volumes is that they all need what's called a 'control block'. There's a special word for this in Unix - I know, I know, just bear with me, with Steve - and it's 'ilist'. The Unix volume control block is called the 'ilist'.

Yes? Yes, 'vnode' is also used, instead of 'inode'. They're interchangeable for our purposes. Any other questions?

OK. Half an hour until coffee. Are you guys going to make it? Are you sure?

So. Volume control blocks. Ilists. Each volume has its own proprietary control block. This is where the volume keeps all information it needs to afford you, the user, satisfactory access to the files on that volume.

And the files on each volume are put into what are called 'folders', or 'directories'. A Unix directory is just a file like any other file. All files on Unix are essentially the same. There's no more sequential access or whatever they called it, there are no special methods for reading directory data, or any control characters in the directory files themselves. They're just files like anything else. And, you might not find it a big deal today, but back then, the idea that a file was just a 'stream of bytes' without control characters: that was a big deal, OK?

Unix directories are always eminently simple. But even more so forty years ago. Back then, the first versions of Unix, filenames were at most sixteen bytes in length. A directory entry had only two things: the inode, or the control block index, and the filename. Filenames had to be unique. For any given directory. Not the inodes. You could have the same nodes as many times as you wanted in the same directory, as long as their corresponding filenames were still unique.

And yes, the same filename - with the same inode - could appear in another directory. But the same rules apply for the other directory as well. Otherwise you could have the same filename with the same inode in as many directories as you wanted. Given the aforementioned constrictions.

But it's very important to remember that, on Unix, directories are just files like any other file. Repeat that, OK? Directories are just files. Directories are just files. Directories are just files. OK, that's enough. You seem to have got it. But don't lose it, OK? For now we're going to jump over to the concept of access control.

And I'm going to be speaking in broad brush strokes, so to speak.

We need to be familiar with two general types of access control. As apply to computer security. Oh wow, someone in the back row just woke up!

Anyway. We need to talk about discretionary access control and mandatory access control.

First: discretionary access control. Discretionary access control is where you can decide to control access to a filesystem resource. Or not. The original Macintosh had, at best, discretionary access control. Basically if you could get at the physical Macintosh, you owned it. You could access everything on it. It didn't matter if a file were marked 'read only' because you could change that.

Microsoft Windows works much the same way today. Yes, yes, yes, they have additional methods of access control today, thanks to their infusion from Digital Equipment, but they're still mostly discretionary. Meaning the user in control of the system can decide whether to control access to filesystem resources or not.

That's the world of the Macintosh, which didn't really have an operating system, only a disk operating system, and it's essentially the world of Windows today, which is one of the chief reasons that Windows will never be safe for use. OK, calm down.

Anyway.

Because, in the world of Unix, we have mandatory access control. That means that you have to institute access control for every resource in a filesystem whether you want to or not. That's how Unix works. Let's just say that Unix was designed by PhDs at Bell Labs but Windows was designed by a Harvard dropout. OK, come on.

Now you can still grant full access to everyone, but the point is that you have to specify it. You don't need to do that with the Macintosh or Windows. Here in Unix you do.

So what kinds of access control do we have in Unix? Anyone know? No? OK, a few, OK.

At the most basic level, and we're not talking about access control entries or access control lists, if anybody's thinking that, we're just talking basic fundamental dark ages Unix access control. There are three types of access, and the three types apply to three divisions of users or user groups.

Let's take the users and groups first.

The first user to consider is you. You, the user who creates a resource - a file, whatever. Who creates a directory. You create it, you own it. You're the user. You could also call yourself the owner. That sounds even more appropriate, but you'll run into trouble with nomenclature in a while. So let's just call you the 'user', and keep in mind that makes you the 'owner', that 'user' and 'owner' in this context are equivalent.

Next consideration: user groups. All Unix users belong to one or more user groups. This concept is used in order to apply the same access control to more than one user. You as the default user on a Mac are a member of the group 'staff'. You might also be a member of the group 'admin'. The Unix superuser - everyone heard about the superuser? No? Well OK. The superuser is like a super-administrator. A special account with special and very powerful privileges. It's often called 'root' as well. And the 'root' account is normally associated with the user group 'wheel', as in 'big wheel'. Yes, they're funny at times, those PhDs.

So now we have two types of users or user groups for specifying access control. The owner of a resource - the 'user' - and a user group for that resource.

The third and final type is simply 'everyone else' - or in Unix parlance: 'other'. Now you see why you can't call the owner the owner. Unix will refer to these three types as 'U', 'G', and 'O' respectively.

In Unix, if you create a resource, you own it. It's yours. And, as the owner/user, you get to decide what user group the resource is to be associated with. This must be a user group you belong to. And you also get to decide what access each of those three get.

You can, for example, completely cut off access to your own resource. Or file. Or directory. You can mark it so even you can't get at it! But of course, as you're the owner, you can change that at any time, whereas other users can't.

Actually I'm not sure if this is working properly on this Mac here. Access rights for 'everyone else', or 'other', do not apply to you the user or owner, only for those who are not you. This seems strange. OK, the behaviour seems to be consistent at any rate. OK.

So. Anyway. Those are the three types of user or user group specifications. Now we have to look at the three types of actual access. These will apply to the users and groups.

The first type of access is Read. Note this applies to all files, even directories. If you don't have Read access to a file, then you can't see what's in it. If you don't have Read access to a directory, then you can't list it. OK?

The second type of access is Write. Again, this applies to all files, even directories. And this is very important when it comes to directories. We should be able to touch on this later. If you don't have Write access to a text file, for example, you can't update it. Yes, I know. Save that for later OK? And the same goes for directories. You literally cannot copy files into a directory if you don't have Write access. You can't move files out of a directory if you don't have Write access. You can't even rename a file in a directory if you don't have Write access. Does anyone not understand why? Good. Because the information for that directory is in the directory file itself. Yes, exactly.

The third and final type of access is eXecute. Or 'run'. This 'X' bit applies to program files, but it also applies to script files, and it also applies to directories.

A famous tutorial by Brian Kernighan - anyone heard of him? No? Brian's book on Unix programming begins by creating a script file, saving it to disk, then encountering a quandary when it won't run. And that's because you have to explicitly set the 'X' or 'run' bit.

The same applies to directories. You can't 'enter' a directory if the 'X' bit isn't set. Yes, correct. You can't set a directory to your 'working directory' without the 'X' bit. OK, if you don't know what that means, just let it go, for it's time for coffee! But to recap before you all rush out:

We touched on secondary storage, the manifestation of the filesystem. We brought up the concept of the 'volume'. We talked about discretionary and mandatory access control. And then we went into the three types of access to any filesystem resource, and they're expressed for each of three users or groups on the system. And these filesystem attributes apply across an entire volume. And your Mac can have many volumes, some of which are physical and some of which are logical.

OK, twenty minutes. We need to be back here in twenty minutes. I'm told they have coffee, even decaf coffee, English breakfast tea, some sort of herbal tea, hot chocolate, freshly squeezed orange juice, grapefruit juice, sandwiches, and fresh fruit. OK, enjoy - back in twenty, OK?

**

Hi. Welcome back. You're all feeling better? Hey - fresh bananas! They didn't mention that. Chiquita! Everybody ready to go again?

OK, to recap again. We touched on secondary storage, filesystems, volumes, users and user groups, and access control. And here we're always working with mandatory access control, and that's what makes our Macs more secure than Windows. Any questions before we move on?

Yes. Lunch. We should be finished by lunch, which is at 1 PM. After that you're free for the day. OK. Any more questions? No? Fine.

OK, so in this part I want to show you how mainstream Unix handles what we touched on before the break.

The three main interfaces for Unix are Gnome, KDE, and Apple's macOS. Of course there are others, but these are the 'big three', so to speak.

We'll take KDE first. 'KDE' stands for the 'K Desktop Environment'. It predates Gnome, and Gnome is purportedly a reaction to KDE.

This is the KDE 'Konqueror' file manager for KDE.



'Konqi' has a bit of everything. One might even say a bit too much. But let's look closer.

There's that strange toolbar down the left margin, in addition to the toolbar at the top. Then there's a directory tree. This is important, as Unix can have hundreds of thousands of directories, but here we don't see much of the actual hierarchy, although the '+' signs indicate that those hierarchies can be expanded.

Now we come to the actual file data columns in their tableview. They call it a 'list view', but same difference.

The headers in this tableview, by the way, can be clicked to set the ascending or descending order. There they're sorting descending in the 'Owner' column.

First on the left is 'Name', which is appropriate, as that's how most people will sort and it's what you want to see first. Next over is 'Size', expressed in kilobytes. So far so good.

Next is 'File Type'. Using an entire column to say 'Executable' seems a waste. It's doubtful that Konqi went through the trouble of using system logic, ferreting out 'magics' and so forth, to try to determine, actually guess, at a file type. More likely is that the system found the file's eXecutable bit, just like what the Mac does.

Next over is the 'Modified' field. Unix has always had three time fields, and today has four. Another time field is found much further to the right, but why are they separated?

Next over is the 'Permissions' column. The permissions are expressed as three groups of Read Write eXecute ('rwx') but something could still be missing there.

The next two columns are 'Owner' (user) and 'Group'. Then the mysterious 'Link' which seems to potentially be problematic - leave that for now.

Then the 'Accessed' time field. Then the 'Mime Type'? Then the 'URL'?

Yes, something seems wrong there. It's overkill. It's full of redundancy. The major complaint against KDE in general was that it was too 'nerdy' and didn't understand the elegance and power in simplicity.

So let's look at the other offering. Gnome.



Gnome has a more pleasant layout, seems a lot less cluttered. But let's see what we have.

On the far left we see the Ghost of Windows Present, the nonsense of 'Home Folder' at the top. Microsoft invented something for Windows 95 and then Windows NT 4.0. They call it the 'Shell Namespace'. What were they thinking? At the very top of Microsoft's hierarchy, they have 'Desktop'. But 'Desktop' isn't at the top of any hierarchy. It's right where it is on the Mac. But it's also in its true location on Windows as well. So Microsoft put the same node at two locations. Geniuses. And here it seems a bit of the same.

Otherwise, moving to the right pane, we actually see a lot of the same we saw with KDE's Konqueror. Name, Size, Type which actually is Mime Type, Modified titled 'Date Modified' even if it's also the time, Accessed, Group, MIME Type which appears to be the same as the earlier Type column, Owner which appears first here, Permissions as text, then Permissions in the more common octal, so permissions twice?

Yes, in an effort to simplify things, the people at Gnome actually made things more complex, more confusing, and often contradictory. Not good. KDE might be ugly, but it edges out. Anyway.

Next up is Rixstep's Xfile. I can't tell you how much I hate this program. I know that some of you use it, and I'm not going to ask why, but I should.



I can't explain what it is about this Xfile, because it makes a lot of sense actually. That tree hierarchy on the left is easy to read, but maybe this is only because there's more room. The columns are limited to Name, Size in bytes, Inode which the other two did not have, Links which the others didn't have either, Owner, Group, Modified, and Mode expressed only once in octal.

The program looks tidy and minimal and takes only 140 KB on disk, all told. But I hate it. I can't explain why, but I do.

Anyway. Those are three manifestations of file management on Unix today, one of which exists for the Mac.

So here's the question - or questions - to you.

* What's missing from the Mac file manager?

Specifically think about the following.

* Gnome was a reaction to KDE. It was an effort to make things 'simpler'. Both Gnome and KDE have 'icon views'. But, in 'detailed view', they have equivalent layouts. Do you think Gnome is too difficult for ordinary users?

* Gnome, KDE, and Xfile can all set full permission bits. The Mac file manager cannot. Why?

* Why does your file manager conflate different security concepts? Why do you have 'everyone' there?

* The fact that you have no 'tree view' like Gnome, KDE, and Xfile leaves your file manager severely limited. Your 'outline view' becomes burdensome and a real memory hog in no time flat. Why haven't you replaced it?

* There is no mention in your file manager of access control lists. Why not?

* There is no mention in your file manager of file flags (chhflags()). Why not?

* There is no mention in your file manager of extended attributes. Why not?

* Is any of this because you don't yourselves know or would rather you didn't know?

* All told you have three concurrent access control systems, of which you only show your users one. How do these systems compete? Do you yourselves know? When were you planning on divulging these secrets to your users?

* Why do you practice deception? Do you think they'll appreciate what you've done and be grateful once they discover what you've been doing?

* Do you think it's better to hide the truth rather than think more of your users?

* You might, for example, have issued a warning to users when they ventured into system areas where they might hurt themselves. But the truth is that they could hardly have hurt themselves anyway. You were more interested in simply hiding the complexity of the system - and you did this not by warning people about venturing into system areas but by trying to hide those areas so your users wouldn't even know they were there. Can this be right?

* Does any or all of the above make you sleep better at night?

OK that's all for today. We get out a bit early. The exam's in the middle of next month.

Thanks for your time. Happy Thanksgiving! Drive safely.

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.