-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MDJ 2002.12.19 (December 19, 2002)
==================================

   Copyright 2002, GCSF Incorporated.  All rights reserved.


Top of the Day
--------------

**The big story**

  Features, features, features! MacCyclopedia starts today with a
  brand-new double-length John C. Welch look at permissions. Not
  just in Mac OS X, either: we cover the differing AppleShare
  privileges in Mac OS 9, how Mac OS X's Unix-based model differs,
  and why the Novell-Windows model of Access Control Lists is the
  future. Along the way in this journey, we stop to look at local
  privilege options in Mac OS 9, how AppleShare IP differs from
  traditional AFP, and why the Mac OS X 10.2 Finder doesn't quite
  tell the truth about some permissions. If you're confused about
  access privileges, this should go a long way towards clearing it
  up, presented in one part as a special bonus.

**QuickBooks Pro 5**

  The equivalent of our third feature today is Delivery Dock, with
  the first part of our look at QuickBooks Pro 5. Unfortunately,
  QuickBooks is not merely the best-selling small business
  accounting software in the world, it's a Macintosh meme with its
  own history of betrayal and resurrection. Can you buy into a
  program with such a history? We've mentioned the pieces of the
  puzzle this year, but you can't evaluate QuickBooks Pro 5
  without considering Intuit's history of Macintosh dumping and
  bad business decisions. In part one, we lay it out with
  documentation, for it's the only way to understand why the
  program has few new features - and why that may not be a bad
  thing, as we'll explain in the next part.


Delivery Dock: QuickBooks Pro 5
-------------------------------

**Part 1: Can Intuit overcome its own history?**

  In August, Intuit announced that it was returning to the
  Macintosh small business accounting market after six years on
  the sidelines. QuickBooks Pro 5 for Macintosh [1] is the first
  non-bug-fix update for the platform since Intuit released
  QuickBooks Pro 4 in late 1995. It's exciting news for small
  business owners who want to run their companies on a Macintosh,
  because QuickBooks is clearly the biggest name in small business
  software. Yet this much anticipated new version cannot be
  evaluated in a vacuum.

  [1] <http://quickbooks.intuit.com/qbcom/jhtml/skins/prod_ovw.jhtml?ssaPath=qb_2003_mac_pro_1user>

  QuickBooks is not just a program, it's an empire, and it's one
  that explicitly dumped the Macintosh six years ago.  It comes
  from a company with a history of dropping Macintosh products
  even when they have 60% market share or more, even after it has
  promised it wouldn't do that. The program carries this baggage
  with it, and it's extremely relevant to anyone who was using
  QuickBooks Pro 4 for Macintosh and had to change to another
  solution when Intuit refused to update the program. Before
  examining why the program has few new features, we must explore
  its context.

**Dropping QuickBooks**

  In November 1996, Intuit notified tens of thousands of customers
  that it would no longer develop QuickBooks for Macintosh. Intuit
  told customers in its "goodbye" letter that the Macintosh
  version was not a good investment because only 5% of QuickBooks
  customers used the Macintosh version. The fact that the
  Macintosh had only 5% market share didn't seem to sink in:
  Intuit's management was, in essence, arguing that unless
  QuickBooks for Macintosh could get two to three times more
  market share in business than the platform had in general, it
  wasn't worth updating.

  But more of Intuit's reasoning became public in January 1997.
  The _Wall_Street_Journal_ covered another Apple Computer
  quarterly loss [2] on declining revenue by describing, yet
  again, how the platform was sinking and developers were
  deserting the Macintosh (MDJ_ 1997.01.16). Reporter Lee Gomes
  wrote:

  [2] <http://www.apple.com/pr/library/1997/q2/970115.pr.rel.q197earning.html>


    Because of the news, some analysts who had been believers
    in the Apple turnaround story a few months ago are
    starting to have doubts about whether the company can
    rebound. [...] Software companies are also growing
    increasingly alarmed at Apple's slippage, and as a result,
    some major ones are edging away from the Macintosh.
    Intuit...won't bring out new versions of its QuickBooks
    account program for the Macintosh, despite QuickBooks' 60%
    share of the Macintosh accounting-software market. Said
    Day Nye, QuickBooks product manager, "We could not justify
    the development costs. The market wasn't big
    enough."


  That's right: Intuit held over 60% of the Macintosh small
  business market (at US$200 per copy of QuickBooks) and couldn't
  figure out how to make money on it, when other companies were
  doing fine fighting for the other 40% among them.  Macintosh
  users were outraged that Intuit was dropping such a vital piece
  of software to their businesses. In response to tens of
  thousands of complaints, Intuit offered a discount on QuickBooks
  Pro for Windows.

  It was neither the first or last Macintosh attack from Intuit's
  management. Earlier in 1996, Intuit dropped support for MacInTax
  ProSeries, the accountant's version that generated tax returns
  for other people and supported just about every IRS form. (It's
  been lost in the mists of PC-centric computer history, but
  MacInTax was actually the original product. TurboTax was a later
  PC version, and Intuit acquired both when it merged [3] with the
  original developer, ChipSoft, in 1993.) When dropping the
  professional Macintosh version, Intuit's management swore it
  wouldn't do the same with other Macintosh product - just a few
  months before giving QuickBooks for Macintosh the axe. The
  company dropped MacInTax for Business in 1999 (MWJ_ 1999.09.18).

  [3] <http://www.lysator.liu.se/amiga/ar/guide/ar123.guide?P1-2>

  In 1999, Intuit stopped supporting payroll tax tables for
  QuickBooks 4 for Macintosh, instead sending every registered
  user a copy of Aatrix Top Pay [4], a stand-alone
  payroll-processing program that works with QuickBooks 4. That
  was part of a program upgrade that fixed a Y2K bug that Intuit
  acknowledged in January 1999 but didn't fix until June:
  attempting to enter any date beyond 1999.12.31 crashed the
  program. At the same time, though, Intuit discontinued the
  "advanced support" it had promised Macintosh customers in 1996
  when it discontinued QuickBooks development. Even worse, the
  updated version (numbered "4.0M13") required changing a
  QuickBooks data file so that no other version of the program
  could read it, ending the ability to move it to a Windows
  version or even send it to a Windows-using accountant.

  [4] <http://www.aatrix.com/1.800.426.0854/top_pay/>

  Having dropped support for business versions of tax preparation
  and accounting software for Macintosh, Intuit turned its axe to
  personal finances in 1998. The company announced it would not
  make a new version of Quicken that year (what would have been
  "Quicken 99") because it couldn't justify upgrading a product
  used by 75% of Macintosh owners that tracked personal finances
  (MWJ_ 1998.04.20). Intuit said Apple's support for the consumer
  market was too tenuous to spend the money upgrading Quicken for
  Macintosh, and instead "reassigned" the Macintosh engineers to
  work on the Quicken.com Web site. It was a sham from the
  beginning: Intuit made its announcement just a few weeks before
  Apple introduced the iMac, and as top Macintosh developers whose
  CEO was on Apple's board of directors, Intuit certainly knew
  about the new machine and chose to publicly humiliate Apple
  anyway.  The situation was resolved when Apple paid Intuit to
  hire engineers to work on a Macintosh version and agreed to
  bundle Quicken with iMac computers, paying Intuit millions of
  dollars in extortion money to keep supporting Macintosh
  customers (MWJ_ 1998.05.11).

**Mmm mmm bad** -- You can blame a lot of this on Intuit's
  management at the time, a group of people selling financial
  software despite a proven ability to lose money in almost any
  situation. Intuit lost money in four of the last nine fiscal
  years, with negative operating income in six of the past nine
  fiscal years. The company made such wise business decisions as
  paying millions of dollars for a 20% stake in the now-defunct
  Excite Web portal, and despite a huge lead in market share over
  any other competitor (and a healthy lead over Microsoft Money),
  couldn't figure out how to turn a profit.

  The tide seemed to turn when long-time CEO Bill Campbell stepped
  down, becoming Intuit's chairman.  Bill Harris, the former
  president and CEO of ChipSoft, replaced Campbell in August 1998,
  but Harris stepped down [5] just over a year later to be
  temporarily replaced by Campbell again. Current president and
  CEO Stephen Bennett took Intuit's reins [6] in January 2000, and
  things have been looking up since then. Intuit posted a profit
  in fiscal year 2000, the one that was more than half over when
  Bennett took the job, but mostly on investment income.  In
  fiscal year 2001, the absence of such investment gains plus
  accelerated write-downs of previous acquisitions led to a GAAP
  loss [7], even though revenues were up.  Intuit seems back on
  track with a decent fiscal 2002 profit [8], even by GAAP
  standards.

  [5] <http://www.intuit.com/company/press_releases/1999/09-23.html>
  [6] <http://www.intuit.com/company/press_releases/2000/01-24.html>
  [7] <http://www.intuit.com/company/press_releases/2001/08-21.html>
  [8] <http://www.intuit.com/company/press_releases/2002/08-14a.html>

  Under Bennett, Intuit's philosophy has shifted to making
  products that are "right" for specific customers. For
  QuickBooks, the "right for your business" plan [9] has led
  Intuit to make versions of the program aimed at specific
  markets, such as for accountants that support small businesses,
  a construction edition, a version for larger businesses [10], a
  Web-based version, and a new SDK [11] to let developers add on
  to QuickBooks as a platform. (Previous versions of QuickBooks
  were closed more tightly than Scrooge's pre-dream pocketbook.)
  On the consumer side, "Right for me" has led to several new
  versions [12] of TurboTax, depending on the financial goals of
  the purchaser.

  [9] <http://www.intuit.com/company/press_releases/2001/11-27.html>
  [10] <http://www.intuit.com/company/press_releases/2002/04-02.html>
  [11] <http://www.intuit.com/company/press_releases/2001/11-27b.html>
  [12] <http://www.intuit.com/company/press_releases/2002/09-17b.html>

**The new Macintosh unit**

  QuickBooks development had always been carried on in a single
  unit, with a few programmers working on the Macintosh version
  and everyone else working on the Windows versions. That's what
  Intuit couldn't make profitable six years ago. This year,
  following the "right for your business" strategy, a team of
  Macintosh folks within the company pitched Intuit management on
  a radical idea: the Macintosh platform is not dying.

  Other companies that earlier fought over the 40% of the market
  not occupied by QuickBooks had done better in Intuit's absence.
  A 1999 MacCentral report [13] on accounting software - pre-Mac
  OS X - listed over a dozen alternatives ranging in scale from
  shareware to database-driven cross-platform systems. There are
  still several commercial small business accounting packages
  available for both Mac OS 9 and Mac OS X, including CheckMark
  Mac MultiLedger [14], Aatrix Accounting [15] (formerly
  Peachtree), Big Business 4 [16], Flexware Accounting [17], and
  ResellerPower [18].

  [13] <http://maccentral.macworld.com/news/9905/21.migrationkit.shtml>
  [14] <http://www.checkmark.com/mlmfix.html>
  [15] <http://www.aatrix.com/1.800.426.0854/accounting/index.shtml>
  [16] <http://www.bigbusiness.com/v4.html>
  [17] <http://www.flexware.com/FW/FWMac/MacUpdates.html>
  [18] <http://www.resellerpower.com/resellerpower/overview.html>

  The leader of the pack is clearly MYOB and its two annually
  updated products, MYOB AccountEdge [19] and the new MYOB
  FirstEdge [20] for smaller businesses that don't need features
  like international currency or time tracking. MYOB stepped up as
  soon as Intuit vacated the market, releasing QuickBooks file
  conversion kits, special upgrade offers, and support for some
  key Apple technologies. MYOB AccountEdge has supported
  AppleScript import and export of transactions for years, making
  it easy to connect it to automated systems of any kind.  What's
  more, it uses a simple tab-delimited text format. QuickBooks 4
  only imports "Intuit Interchange Format" files. The
  documentation actually brags about this "advanced" file format
  but then refuses to document it.  (In 1996, this journal's
  parent company had to call Intuit technical support and accept a
  10-page fax just to get the basic import information. Intuit
  still doesn't have the specification online, but admits that the
  format is so complex it can't offer you live support [21].)

  [19] <http://www.myob.com/us/products/accountedge/new/>
  [20] <http://www.myob.com/us/products/firstedge/>
  [21] <http://www.quickbooks.com/support/faqs/qbw2002/200767.html>

  MYOB was quick to release a Carbonized small business accounting
  application, unveiling MYOB AccountEdge at Macworld Expo in New
  York in July 2000, shipping it a few months later. Last month,
  MYOB shipped AccountEdge 3, finally catching up with some of
  QuickBooks' long-standing user friendliness, such as allowing
  calculations in money fields and showing a calendar in date
  fields. MYOB has aggressively exhibited in Apple US retail
  stores, courted the Macintosh press extensively, and made the
  company's commitment to the platform clear: MYOB AccountEdge is
  the twelfth release of MYOB accounting for the Macintosh, and
  the sixth new one since QuickBooks 4.0 was released.

  In fact, in May, MYOB announced [22] that it had taken the lead
  in Macintosh small business accounting market share for the
  first time, "ousting Intuit from this spot and outperforming
  CheckMark Software, Inc. and Aatrix Software, Inc." Make sure
  you understand that correctly: even though Intuit had only
  updated QuickBooks 4 for Macintosh once in the past six years -
  an update that removed payroll functionality, made the files
  incompatible with any other version, and fixed only catastrophic
  bugs like a Y2K crasher - it was still holding more than 50% of
  _current_ Macintosh small business sales through April 2002.

  [22] <http://www.myob.com/us/news/releases/archive/general_may30_2002.htm>

  But QuickBooks was not in great shape.  It didn't use the
  Appearance Manager, since that was released about 18 months
  after QuickBooks 4 was.  It used custom pop-up menus that mainly
  served to limit how much information you could see at once. It
  was designed under System 7.5 and didn't support any later
  technology.  Given Intuit's active disdain for the product
  (other than to sell new copies for US$200 a piece for five years
  without mentioning on the box that the product was discontinued)
  and MYOB's active support for the platform, the tide had finally
  turned.

**Enter QuickBooks Pro 5**

  That's also when some Intuit management woke up, realizing the
  company could get first place back and make lots more money if
  it started developing new QuickBooks versions for the Macintosh.
   The company formed a dedicated Macintosh business unit with
  management, engineering, and testing all included.  In August,
  Intuit went public with its plans, announcing [23] that it would
  release QuickBooks Pro 5 for Macintosh in the first quarter of
  2003, with updates coming "on approximately an annual basis."

  [23] <http://www.intuit.com/company/press_releases/2002/08-05.html>

  It was classic FUD (fear, uncertainty, and doubt) marketing. The
  announcement mentioned absolutely no new features other than Mac
  OS X native operation. It didn't mention a price or a specific
  release date, and the promise for annual updates must be taken
  in context with Intuit's history both of management incompetence
  and dumping on Macintosh customers despite massive protests. 
  There was nothing at all to compare to other programs like MYOB
  or Aatrix Accounting. The sole purpose of the announcement was
  to freeze the competition: to make customers think, "Oh! A new
  version of QuickBooks is coming soon! I shouldn't buy anything
  else until I see what it has to offer."

  Now we know what it has to offer, and the answer is, "not much,
  not right now."  The nature of the update has prevented Intuit
  from doing very much to the program other than Carbonize it.
  QuickBooks Pro 5 looks very much like QuickBooks Pro 4 with an
  Aqua interface. The strange thing is that may be the best
  alternative Intuit had, even though it's a tough sell.  In part
  2, we'll look at exactly what QuickBooks Pro 5 has, what
  Intuit's Macintosh developers have to say about it, and what it
  means.


MacCyclopedia[tm]: Permissions
------------------------------

**It's more than reading and writing files**

  One of the biggest changes Mac OS 9 users run into in Mac OS X
  is the new permissions structure, That's "run into" as in "large
  truck hitting a bridge": sudden, shocking, and somewhat painful
  for the truck driver. People who are used to the ability to
  delete just about any file are suddenly frustrated when the
  system says, "No, these files belong to me, and you cannot
  change them." You have to prove who you are to Mac OS X to delve
  into certain areas of the system, including installing software.
  These issues have tripped up a lot of people, but they really
  aren't the vast chasms that they may appear to be at first.

**What are permissions?**

  Permissions are a way to regulate what users can perform what
  actions in a given situation. They determine what tasks you are
  authorized to perform, based on how you are authenticated on a
  given system and, if present, a given networking scheme.

  The first problem is confusion over authentication and
  authorization. Authentication identifies you to the system, but
  does not determine what you are allowed to do. Authentication
  says, "This user is allowed to log in to this system based on X
  information." Common authentication mechanisms include user
  names and passwords, smart cards, and biometrics. They get you
  in the door. What you are authorized to do once you are in the
  door depends on permissions. Authorization schemes can use
  authentication mechanisms, but the two terms are not the same.

  Permissions determine if you are allowed to add files to a
  folder, mount a volume, delete a file, open a file, and perform
  similar tasks, but they don't exist in a vacuum. In general, a
  permissions scheme maps three levels of people: the owner, the
  group, and everyone else, to tasks available on the system. When
  they work correctly, permissions schemes are fairly transparent
  until you try to violate them, but when they are messed up, they
  can be amazingly painful to deal with. One of the first problems
  Mac OS X users have is that permissions are vastly different
  than under Mac OS 9, so we'll first look at how each OS handles
  permissions.

  One thing to keep in mind is that permissions are a part of a
  security scheme, not a complete scheme by any measure. One of
  the first things any would-be attacker learns is how to blow by
  the permissions scheme in a target OS. It's probably better to
  think of permissions as an easy way to prevent accidental
  problems. If you need "real" security, you need to look at
  mechanisms such as encryption, user activity logging, and
  authentication schemes that also provide authorization (like
  Kerberos). Permissions are useful, but they're not a panacea.

**Permissions in Mac OS 9**

  You may not think Mac OS 9 doesn't have any permissions issue,
  but that's not strictly true: it just doesn't have any formal
  local user permissions. If you are sitting at a typical Mac OS 9
  system, you are, for all intents and purposes, the lord and
  master of that system. There are files that you can't easily
  delete, like the Finder and the System File, but that has
  nothing to do with a permissions scheme: the Finder has a few
  precautions built in, and you'll get errors if you try to delete
  files that are in use, like the System file. All operating
  systems, regardless of permissions structure, have similar
  rules. That's just common sense. There is, however, no intrinsic
  part of Mac OS 9 that says, "User A can't touch User B's files."

  Although not built-in, there are ways to add local permissions
  to a classic Mac OS system. Apple provides Multiple Users for
  Mac OS 9 and Macintosh Manager for networked systems. These, and
  other third party add-ons, allow you to set up local permissions
  structures that can keep users from doing bad things to other
  users' files, as well as to the system's files. The problem with
  these schemes, regardless of source, is Mac OS 9: a single-user
  operating system that was never designed to support permissions.
  Some things just never seem to work right under these various
  schemes, or at least, not without a lot of work from the
  administrator.

  Another problem is that most of these schemes are implemented
  via extensions. This adds the fun of extension conflict issues
  to the other issues with such mechanisms, making troubleshooting
  in these environments even more complicated. Apple's At Ease
  even replaced some system software components with its own
  versions, creating even more potential for complicated problem
  solving. Locally, you had the choice of no permissions at all or
  grafts of various permissions schemes that work with different
  degrees of success and stability.

**AppleShare and share alike** -- Once you start using Macs on a
  network, however, permissions are a different story. There are
  plenty of permissions issues in the classic Mac OS, but they all
  involve AppleShare. Since AppleShare is based on the Apple
  Filing Protocol networking standard, the permissions are usually
  referred to as AFP permissions. Even that's not enough, because
  there are two tracks: traditional AFP permissions and the
  permissions structure used in AppleShare IP.

  The traditional AFP permissions regulate three tasks: See
  Folders, See Files, and Make Changes. If you wanted to set up a
  folder as a drop box (one that allows other people to put files
  in the folder but not see the contents of the folder), you would
  set that folder to only allow "Make Changes" for people that
  should be allowed to drop files in the box. Disabling "See
  Files" on a folder but leaving the other two settings enabled
  gave you a folder to which you could add files but not see any
  files in the folder (and yes, in a proper AFP implementation,
  any file you added to such a folder would "vanish" in the
  Finder).

  It's important to note that AFP permissions apply to folders,
  not files. AFP file permissions are implied by the folder
  settings [24]. If you can "See Files" and "Make Changes" for a
  given folder, then you can modify a file in that folder. If you
  can't "Make Changes" on the folder, then you can't modify the
  contents of that folder, so you can't delete or write to a file.

  [24] <http://manuals.info.apple.com/Apple_Support_Area/Manuals/servers/AppleShare3.0UG.PDF>

  Traditionally, systems like Unix include a separate execute
  permission (for permission to launch a file as a program) that
  AFP does not support. It's more important in Unix than in Mac
  OS, anyway: many Unix programs are shell scripts stored in text
  files, and it's useful for a system administrator to say "you
  can read this file and see the code in the file, but I don't
  want you running it." There's never been a similar analog for
  classic Mac OS (AppleScript can't execute scripts stored as text
  files, only as compiled scripts or applications), and the
  privilege never really percolated through to the Mac OS.

  Instead, permission to "launch" a file is implied with AFP
  permissions. If you can "See Files" and "Make Changes," you can
  run an application that needs to make changes to its own file
  (highly discouraged for just this reason) or to write files in
  the application's own folder. If the program doesn't need to
  write to any file in its own folder, all you need is the "See
  Files" permission to run an application. This permissions scheme
  was actually quite flexible, but it had no direct analogy to
  other permission schemes. For administrators from other
  environments, mapping other permissions schemes to this one was
  a bit of a headache at first.

**AppleShare IP Freely** -- So Apple changed the permissions in
  AppleShare IP 5.0, the first TCP/IP-based version of the server
  and client software. The new scheme was based on two explicit
  permissions instead of the previous set of three: Read and
  Write. All permissions are based on various combinations of
  those two settings.

  Enabling all three permissions under the old scheme maps to
  "Read and Write" under the new scheme. "See folders" and "Make
  changes" maps to "Write Only." However, just "Make changes"
  without "See folders or "See files" also maps to "Write Only."
  Under the old scheme you could open a folder but not see any
  files inside it or make any changes by setting the folder
  permissions to "See folders." The closest thing to this under
  the AppleShare IP scheme is "Read," but that grants the ability
  to see everything in the folder. There's not even an equivalent
  under AppleShare IP for the combination "See files" and "Make
  changes." The AppleShare IP scheme is simple to understand, but
  less capable than original AFP permissions.

**The user structure** -- Both AFP and AppleShare IP permissions
  apply to one of three categories of person: the Owner, the User
  or Group, or Everyone. The "owner" of a file or folder is the
  only person or group that can change permissions for the folder
  (unlike Unix, in AppleShare, a group can own a file or folder).
  The "user or group" is an extra category, a user or group that's
  not the owner but can have a specific set of permissions for a
  folder and the files within it. Even if you give that user or
  group all permissions to a folder, they don't _own_ it and can't
  change those permissions. The user or a member of the specified
  group can delete files in that folder but not change
  permissions.

  The default category of "everyone" applies to all users that
  aren't the owner or in the "user or group" category. "Everyone"
  is the category that creates the biggest holes in any security
  setup. Any folder accessible in any way to "everyone" grants
  that permission to all logged-in users, even guests if a file
  server allows it. It's usually wise to limit access in the
  "everyone" category as much as possible.

  Administrator users exist outside of these categories. You've
  probably seen this yourself with File Sharing. It doesn't matter
  how many folders you set up to share: when you log in as
  yourself, you see all volumes on the system, not just the
  folders that other users see. With full-blown AppleShare or
  AppleShare IP, you can create individual or groups of
  administrator users that similarly exist outside of the normal
  user structure. This is as it should be, as an administrator
  should be someone who can control what other users can do. Being
  able to alter permissions on other user's files is a crucial
  part of the task, especially as your network setup grows bigger
  and more complex. Therefore, regardless of how you set file
  permissions, there is always at least one user and possibly many
  that can override them.

  There are also levels of users within AppleShare IP who can have
  different administrator permissions levels. You can create
  network administrators, workgroup administrators, as well as
  normal users, and all can have different permissions over a
  given file or folder. A full exploration of AppleShare IP
  administrative permissions is beyond the scope of this article,
  but you can read more in the AppleShare IP documentation [25].

  [25] <http://docs.info.apple.com/article.html?artnum=50036>

**Permissions in Mac OS X**

  Mac OS X is built on a Unix foundation and therefore requires
  Unix-style permissions. Let's dispel any thoughts to the
  contrary right now: without traditional Unix permissions, Unix
  programs would not run correctly on Mac OS X, destroying much of
  the benefit of basing it on Unix in the first place.

  Mac OS X uses the basic Unix three-level permissions scheme:
  read, write, and execute. That's obviously closer to the older
  AFP permissions scheme than the two-level AppleShare IP
  permissions scheme. But unlike Mac OS 9, Mac OS X has local
  permissions. In Mac OS X, every user is restricted by available
  permissions, including a human sitting at the computer. It's not
  just limited to people who connect to the computer over a
  network.

  Another important difference is that by default, even an
  administrator user does not possess ultimate cosmic power over
  the machine. Even if you are the only user on the computer, the
  OS restricts your actions and abilities. This is just how Unix
  works, and therefore is how Mac OS X handles users to keep them
  from doing something silly. There are aspects of Mac OS X that
  Apple doesn't want you to be able to mess with easily: changing
  the permissions on the wrong object, like your boot drive, can
  render your system unbootable. This bothers many long-time
  Macintosh users, largely due to the perceived loss of status
  ("Why do I have to ask for permission? I own you!"). There are
  ways around permissions, either via the sudo command-line tool
  or by authenticating to temporarily gain more powers in the Mac
  OS X 10.2 Finder. However, in general, there aren't many reasons
  to try and bypass Mac OS X's local permissions structure. The
  system wants you to leave the system's own files alone.

  Of these three permissions levels, the standout is "execute."
  Under Mac OS X, permission to execute a file (or folder - more
  on that shortly) is not implied as it was with AppleShare
  permissions. "Execute" is now an explicit permission that can be
  enabled or disabled separately from "read" and "write." While
  this may seem odd, it has some pretty neat effects. You can turn
  off the "execute" bit for programs via the chmod command-line
  utility or many third-party Aqua-based programs. For example, if
  you turn off "execute" for "everyone," then only the owner or
  group can actually launch the program even though it's visible
  to everyone.

   "Execute" isn't just for files - counter-intuitively, it
   applies to folders as well. Unix considers enumerating a
   folder's contents to be "executing" that folder. If you want
   people to be able to use specific files in a directory but not
   get a listing of other files in that directory, turn off the
   "execute" permission. If the "read" permission is off and the
   "write" permission is on, you have a drop box. If "read" is on
   but "write" and "execute" are off, you have a nice way to allow
   people to download or access files, but only if they have a
   direct pathname to those files. This scheme also brings back
   some of the abilities from the older AFP permissions, such as
   being able to run applications without being able to view their
   enclosing folder. But unlike the older AppleShare permissions
   (AFP or AppleShare IP), Mac OS X permissions explicitly apply
   to _files_ and can be different from the permissions of the
   enclosing folder. Folders have permissions, too, but they don't
   control the permissions of every file contained in that folder.

**User structure differences** -- Just as with AppleShare IP,
  Mac OS X applies permissions to three categories of people: the
  owner, the group, and everyone. Note that there are some
  differences in Mac OS X, though. First, only a user can own a
  file in Mac OS X, not a group. This seems like a pretty serious
  limitation, but in reality it's not. Administrators still exist
  outside of the normal user structure. However, in Mac OS X, only
  the superuser (the root user, in Unix terms) and the owner of a
  file or folder can alter its permissions.

  It would be a security hold of astounding proportions if every
  administrator had the password to log in as "root" (the other
  half that authentication, the user name, is always "root").
  However, anyone who is an administrator can _act_ as root when
  needed, even if logging in as "root" is disabled (as is the Mac
  OS X default). Users can act as root from the command line with
  the sudo command ("super-user do," as in "super-user, do
  chmod"), and you can launch regular Aqua programs as root with
  utilities like Pseudo [26].

  [26] <http://personalpages.tds.net/~brian_hill/pseudo.html>

  You can change permissions from the command line by using sudo
  along with the chmod or chown commands, but people want to be
  able to do this from the Macintosh interface, and rightly so.
  This _is_ a Mac, after all. As it turns out, the Mac OS X 10.2
  Finder lets you do just that. If you are trying to change
  permissions on a file you don't own, or change the owner of any
  file (two tasks that normally only the superuser can
  accomplish), the Finder presents you with an authentication
  dialog box. Enter a valid administrator user ID (the system
  fills in your user ID by default, but you can change it to any
  other user ID) and password, and you can then make changes that
  would normally require the root user's privileges. Since you can
  allow any user to administer files this way, or even create a
  group account (with login disabled) and share the password for
  authentication, you can simulate group ownership of a file or
  folder. It's true that in Mac OS 9, you had this administrative
  ability as well as true group ownership of a file or folder, but
  this is a usable workaround.

  The next category is "group". Not "user or group" as with Mac OS
  9, just "group." That's because only groups can be used in this
  category, not individual users. You can have a group of one
  user, but it must be a proper group. This again is a less
  flexible method than in Mac OS 9, made more tedious by the fact
  that unless you are running Mac OS X Server, the only ways to
  create groups in Mac OS X are either via the obscure NetInfo
  Manager, or one of the even more obscure NetInfo command-line
  utilities such as nicl. Even though there are easy, albeit
  tedious workarounds to this problem, this is one of the areas
  where you really do lose some flexibility from Mac OS 9.

  The final category is "Everyone" (or "others"), and as with Mac
  OS 9, it applies to anyone who is not the owner or in the
  specified group. It's the catch all permission category, and as
  with Mac OS 9, should be watched carefully to avoid opening up
  serious security holes in your system if "everyone" has too many
  permissions.

  As with AFP and AppleShare IP, you can create different layers
  of administrative users. If you have even a single-level
  NetInfo, or Lightweight Directory Access Protocol, (LDAP) domain
  set up, then every machine has two layers: local permissions and
  domain permissions applied by the NetInfo or LDAP server. They
  apply to the "root" user as well. The local "root" user can have
  a different password from the domain's "root" user, and local
  admin users can have different passwords than the domain's
  admins. Having access to the local "root" account doesn't mean
  you have access to the domain's "root" account. However, if you
  can act as the domain's "root" user, you also have root
  privileges on any machine in that domain. In this way you can
  set up multiple admin layers depending on how many layers are in
  your domain. You'll probably need Mac OS X Server documentation
  to accomplish this without serious mental problems.

**Truth in permissions** -- One major problem with permissions
  in Mac OS X centers squarely (no Paul Lynde jokes, please) on
  the Finder. While Mac OS X supports three permission categories,
  the Finder only supports the two categories from AppleShare IP.
  As long as the permissions involve some form of "read" or
  "write," everything is copacetic [27], and you have no real
  problems. But what happens when you set permissions to "execute"
  only? At the Unix level, there are no problems. You can't "read"
  or "write" the file, but you can still "execute" it. Admittedly,
  this wouldn't be of much use for files or folders, but it could
  apply to an application, as noted earlier. However, the Finder's
  "Get Info" function only offers three choices: "Read & Write,"
  "Read only," and "No access." As it turns out, "no access" is
  what the Finder displays when only the "execute" permission is
  set, and that's not a completely bad way to phrase it. Even
  shell scripts won't run with only the "execute" permission set -
  you need to have "read" permission as well or else you can't
  read the file to execute the code inside it. On the other hand,
  "No access" is not completely accurate either, and since the
  Finder isn't showing the true permissions for the file, it can
  confuse users who aren't aware of the limitations of only having
  "execute" permissions.

  [27] <http://dictionary.reference.com/search?q=copacetic>

  Even less accurate in a way that _can_ cause problems is the
  fact that if you have only "read" and "execute" permissions set
  on a file, the Finder shows it as "Read only." This is a
  legitimate problem because you can't assume that "Read only"
  always includes "execute" permission. If you do, you're in for a
  rude shock when you try to execute a script or a file truly only
  has the "read" permission enabled - it won't work at all. But
  the Finder doesn't understand this; it goes by AppleShare IP
  rules that assume "Read only" also implies execute permission.

  This has already caught people who are unfamiliar with the Unix
  permissions scheme off guard, and it's something that Apple
  should not have allowed in the first place, much less up through
  Mac OS X 10.2.3. We aren't trying to be stereotypical pedantic
  Unix geeks here, but the Finder should not describe permissions
  differently than they are recorded on disk. It doesn't simplify
  anything and confuses people who need to know the truth about
  permissions.

**The ACL improvement**

  In the end, neither the AFP, AppleShare IP, or Mac OS X (Unix)
  permissions schemes are that good. Even if Mac OS X allowed for
  group ownership (something seen as a security risk by many
  network administrators), you can still only have one group or
  user as the owner, one group or user with different specified
  permissions, and one set of permissions for all other users.
  Even combining the best of all three systems, you'll quickly hit
  real limits on what you can do, especially as the number of
  users and groups grows.

  There is a better way to handle permissions, one that's only now
  finding its way into the Unix world even though both Novell and
  Windows have had it for some time now. It's a far more flexible,
  and powerful way to control access to files, folders,
  applications, and anything else you apply permissions to, and
  it's called an Access Control List (or ACL).

  ACLs are a fairly logical way to specify different access levels
  for multiple groups and users. You still have an "owner," be it
  a group or an individual user. You still have "everyone", the
  catch-all for people not in any other permissions level. But
  where all existing Mac OS schemes allow only one other category,
  ACLs allow as many extra categories as you need. If you have a
  directory to which Accounting needs read and write access, to
  which Marketing needs read-only access, but to which Bob from
  the California office needs full control, then you can apply all
  of those permissions to that directory. Windows NT, 2000, and XP
  provide full ACLs for local users and domain users on a machine.

  A good ACL system not only allows for more flexibility in who
  gets what permissions applied, but also provides greater
  granularity in the permissions themselves. For example, by
  default, a Windows 2000 folder has six basic permissions: "Full
  control," "modify,", "read and execute," "list folder contents,"
  "read," and "write." The advanced permissions expand that list
  to thirteen, separating tasks like deleting the folder from
  deleting subfolders and files within that folder. You can also
  selectively allow a user or group to change permissions, take
  ownership of a folder, create files or write data, or even read
  the current permissions settings.

  This flexibility is what makes the ACL system superior. Unix
  applies the same three permissions to everything but provides
  different results (such as redefining "execute" for directories
  to mean "list contents"), but Windows 2000 and its successors
  knows the difference between a file and a folder. Files only
  have five basic permissions, losing the "list folder contents"
  setting. This makes almost perfect sense to anyone - there's no
  point in having a "list folder contents" setting for a file.
  Since an executable program in Windows is a file, it has the
  same basic settings as a file.

  We aren't cheerleading for Windows, for it still has huge
  security problems, and some of the ACL settings in Windows give
  quite different results than what you expect. They are, however,
  an example of a better, more flexible way to handle permissions,
  and of one area where Windows leads the Mac OS by a good margin.

**A permissive system**

  Mac OS X and AppleShare permissions are both based on a far
  simpler computing model than exists today, and are rapidly
  becoming unsuited to the needs of modern computing. ACLs are the
  next level of permissions control, and the fact that they are
  gradually overcoming even the amazing inertia of the Unix world
  shows how older permissions schemes aren't as suitable as they
  once were. ACLs are an idea whose time has come, and Apple needs
  to implement them sooner rather than later.

  No matter how you look at permissions, they're here to stay.
  Even personal computers are now multi-user systems and that's
  not going to change, nor is the simple protection that
  permissions provide against boneheaded user mistakes like
  throwing away vital system files just because someone poking
  around doesn't know what they do (and you _know_ someone who
  messed up his System Folder that way, admit it). The shifting
  schemes from original AppleShare through AppleShare IP and Mac
  OS X have been confusing, as has been the addition of local
  permissions in Mac OS X. You should now be equipped to deal with
  these problems, as well as the clash between a file's true
  permissions and what the Mac OS X 10.2 Finder shows you. It's a
  more secure world these days: take charge of it.

  [John C. Welch is the IT Manager for the MIT Police
  Department, a columnist for _MacTech_ Magazine and
  workingmac.com, a speaker at MacWorld Expo, general Mac IT
  curmudgeon, Chief Know-It-All for TackyShirt and the newest
  member of the MDJ_ Staff. He wrote this article exclusively
  for MDJ_, with additional reporting and attitude by the MDJ_
  Staff. His first book, "Real World Mac OS X Server [28]", is
  scheduled to be published by Peachpit Press in April 2003
  and is now available for pre-order.]
  
  [28] <http://www.amazon.com/exec/obidos/ASIN/0201782642/gcsfincorporated>


-----------------------------------------------------------------

  MDJ_, The Daily Journal for Serious Macintosh[tm] Users, is
  published by GCSF, Incorporated.

  Publisher:           Matt Deatherage    <mattd@macjournals.com>
  Staff:               Justin Seal       <justin@macjournals.com>
                       Nathaniel Irons    <irons@macjournals.com>
                       Jerry Kindall    <kindall@macjournals.com>
                       John C. Welch     <jwelch@macjournals.com>

  MDJ_ contains news, information, strong opinion, parody, biting
  sarcasm, and things you need to know.  Those easily offended
  should seek information elsewhere.

  Humans often answer the telephone between 10 AM and 6 PM Central
  (US) Time, Monday through Friday. Voicemail is available at any
  hour.

  This file is formatted as setext.  For more information, send
  email to <setext@tidbits.com>.  A file will be returned shortly.
  It is also digitally signed using PGP technology to verify the
  integrity of the transmission.  Our DH/DSS corporate PGP key may
  be obtained at
  <http://www.macjournals.com/pages/gcsf/gcsf_keys.html#Anchor-GCSF_DSSKey>.

  Copyright (c) 2002 GCSF, Incorporated.  All rights reserved.  All
  trademarks are the property of their respective holders and
  owners.

  GCSF, Incorporated.
  P.O. Box 1021
  El Reno, OK  73036-1021
  (405) 262-1399
  <mdj@macjournals.com>


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPgMHOrH4QMSEyVHCEQLv/ACfQ3bEX+j2RNRDn3UfdDFA2j4ip1AAoJFn
1wcS7LO1aeDxshQJOYwmFw/l
=seuh
-----END PGP SIGNATURE-----