• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: FSRef speed impacts and permission checks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FSRef speed impacts and permission checks


  • Subject: Re: FSRef speed impacts and permission checks
  • From: Mark Day <email@hidden>
  • Date: Wed, 14 May 2008 17:29:18 -0700

On May 14, 2008, at 3:37 PM, Dominic Giampaolo wrote:

Even if a FSRef can point directly to the HFS Node on disk, the OS must
still ensure that all its parent dirs' permissions are met, right? While I
suspect that this check is done only once when the FSRef is created, what if


That is correct and how it has worked for the last 3 or 4
years.

the permissions of a parent dir get changed while the app keeps running -
the FSRefs would then need to be re-evaluated. How is that achieved, i.e.
what mechanisms are used internally to know which FSRefs are affected by


That is not correct - no OS that I know of will re-evaluate
all open file descriptors on a permission change.  It's not
practical nor do I think it is desirable.  You can't just go
and revoke an application's open file descriptor because some
directory above it changed permissions.

An FSRef is not the same as an open file descriptor. It's more like shorthand for a pathname. In fact, the File Manager uses what we call a "VolFS" pathname that identifies the volume and parent directory numerically (much like an FSSpec from The Old Days™).


In older versions of Mac OS X, there was a separate file system called "volfs" that found the appropriate vnode for the given directory ID (much like the way the NFS file server resolves file handles). Then volfs had to walk back up the parent hierarchy to make sure the caller would have permission to access the given item; these checks were separate from the normal pathname processing.

In current versions of Mac OS X (I think 10.4 and later), the volfs file system was removed. Now, volfs-style pathnames are parsed by VFS and turned into a full pathname inside the kernel (by walking up the vnodes' parent pointers). Then it walks down the path as if the caller had passed a full pathname, which lets us leverage the existing permission checks. (As Dominic pointed out, there is caching to reduce the cost of those permission checks.)

In *really* old versions of Mac OS X (like 10.0, maybe 10.1), there was no permission checking for volfs pathnames. If you knew an object's ID, you could access it. That was a security problem.

-Mark

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: FSRef speed impacts and permission checks
      • From: "James W. Walker" <email@hidden>
    • Re: FSRef speed impacts and permission checks
      • From: Thomas Tempelmann <email@hidden>
References: 
 >FSRef speed impacts and permission checks (From: Thomas Tempelmann <email@hidden>)
 >Re: FSRef speed impacts and permission checks (From: Dominic Giampaolo <email@hidden>)

  • Prev by Date: Re: FSRef speed impacts and permission checks
  • Next by Date: Re: FSRef speed impacts and permission checks
  • Previous by thread: Re: FSRef speed impacts and permission checks
  • Next by thread: Re: FSRef speed impacts and permission checks
  • Index(es):
    • Date
    • Thread