[Bouba]

I've read some articles about the possibility to log into macos X from a user folder located on an ipod. This made me think of the implications that such a feature would mean on the entire filesystem.

To be able to have home folders on remote disks, apple would have to do some changes in its netinfo database.

�It would need to support 'alias' like folder location (alias doesn't not refer to the hierachical path of the file but it refers to it as its id number) That would probably mean to drop UFS since it doesn't support aliases.

�Apple would need to set a 'home folder' bit for the folders that are homes - that would make use of the ressource fork from the HFS+ system. To easily find those homes when loading a HD, all the files on the hd would need to be in a database filesystem to know exactly what folders are home folders at all time ie to keep track of those "homes". This is why the guy from beos was hired by apple. With 10.3, apple now has the so called HFSX filesystem that adds plugins to the regular hfs+ (for the moment, the only documented one is the case-sensitivity of the filenames which is now supported and selectable on a per drive basis - new info is available about the HFS+ at developer.apple.com)

�That would mean that we would be able to have home folders anywhere and to be able to load from them even if they are on an ipod, or a remote Computer

�The users control panel would need to be revamped, with the addition of homeless/unspecified home users - these people, to gain admin access, would need to be authorized by an admin. If not they will have normal access. They might be added automatically when a disk that contains a home folder is detected - like remote libraries are loaded in itunes.

�user info would need to be stored in the home folder or at least a copy of it so that the user preferences (login password) could be moved between different computers.

This will add the possibility to have a better synching between two different homes (the one on the computer hard drive, and the one on the ipod) Or even have different synchronisation capablilities depending on the drive (eg: entire home folder, entire home except cache, only documents and preferences, etc...) This would be a really powerful feature of the system.

Oh! if a database filesystem is implemented, it would be possible and really feasible to save search results windows as folders. These folders would have a special sign on them to identify them (In a way similar to the tagging of alias). That would allow fast access to files sharing a common feature no matter where they are on the computer, no matter on what partition or hard drive it is. That could be made in a really elegant way!!! Think about it, it would really work in the user centric finder that panther has!

Edit: some grammar and syntax correction!

[TimmyDee51]

Wow, it's clear that you read that new HFS+ document and you've come up with some good ideas, ideas I think may be close to what Apple has in mind. Correct me if I'm wrong, but don't HFS and HFS+ have a special bit for the Desktop folder like you propose home folders to have? I see this to be a great benefit, especially if HFS+ is as extensible as you say it is. That would make adding a database-like behavior relatively easy, I would think, rather than having to rewrite the file system.

Could this be the way we are headed? Clearly there will come a time when new file systems are necessary, but in the foreseeable future, it looks as though both Apple (HFSX and whatever it brings) and Microsoft (NTFS + WinFS) have gone the way of file system extensions to add functionality and keep backwards compatibility. I wonder if this will be a good thing (added features) or a bad thing (performance overhead). Any thoughts?

[arekkusu]

Netinfo already does the remote home directory thing.

This article mentions Apple has 3000 employee's home directories on the network, so they can log in from any machine.

[Rainy Day]

Actually, the way UNIX filesystems work, this is all trivial because you can mount an HD (or partition) anywhere you want on the directory tree (e.g. at your home directory). In fact, there really is no such thing as separate volumes under UNIX, at least not in the Macintosh sense. The MacOS X Finder gives the illusion of separate volumes on the desktop, but the BSD layer simply see's them as folders inside /Volumes

Check out man mount and man fstab in the Terminal for more info.

This is all done without aliases, btw. Regarding UFS not supporting aliases, it supports UNIX links, which work similar to Mac aliases. See man ln for details.

[Bouba]

I've indeed read the paper on HFS but I wrote the core of this message prior to that reading

I know that you can already have your home folder stored on a server (on mac os X server) and boot from it. Unfortunately, you need the server version and it is not very practical for home users.

Symbolic links are not the same, they refer to the path of the file (they are similar to the shortcuts in windows) you move/rename the file and they break. This is something that we should fear as mac users. HFS allowed us since (well... since a long time!) to be able to have alias pointing to any file. Modifying the name or the place of that file changed nothing: the alias was still good (except in some weird situation or if the file was moved across partitions.


The issue that I see here is concerning the security of the filesystem. If you don't have the privileges of a particular folder, you just can't see what's inside. But if they are in a database, the files/folders that are in that particular folder will be seeable when looking at the database (I might be totally wrong about that since, I must admit, I know nothing about FS !!) So it might be just the ressource fork that will be databased...

[Millennium]

Originally posted by Bouba:
I've read some articles about the possibility to log into macos X from a user folder located on an ipod. This made me think of the implications that such a feature would mean on the entire filesystem.

I like some of your ideas, but I have a few minor nitpicks:
[i]�It would need to support 'alias' like folder location (alias doesn't not refer to the hierachical path of the file but it refers to it as its id number) That would probably mean to drop UFS since it doesn't support aliases.[/quote]
Actually, I'm not sure about this. iPods, as with other hard drives, always mount under /Volumes/drivename. If a Home folder was set to /Volumes/ipodname/dirname, then there wouldn't need to be an HFS ID number. This would also allow for UFS support.

�Apple would need to set a 'home folder' bit for the folders that are homes - that would make use of the ressource fork from the HFS+ system.

Actually, it wouldn't use the resource fork, it would use the metadata structure. Either way, it's something not quite particular to the HFS+ filesystem, but is lacking in many other filesystems, such as UFS.

To easily find those homes when loading a HD, all the files on the hd would need to be in a database filesystem to know exactly what folders are home folders at all time ie to keep track of those "homes".

Actually, this could be done by scrubbing the NetInfo database for all users' Home folders. This would probably be faster, considering that most users in the NetInfo database don't actually have Home folders, and so it would be easier to do this than scan the whole disk (or even a index of the whole disk).

�That would mean that we would be able to have home folders anywhere and to be able to load from them even if they are on an ipod, or a remote Computer

This capability already exists within OSX. The only thing lacking is an interface to any of it, but your idea of homedirs on a remote computer can be accomplished via NFS, while the iPod thing takes a small amount of NetInfo-wrangling but nothing too major.

Granted, NetInfo is Going Away Sometime, to be replaced by an LDAP database. The principle, however, is exactly the same.

�user info would need to be stored in the home folder or at least a copy of it so that the user preferences (login password) could be moved between different computers.

That's something which could be accomplished via FileVault. It's possible that this was included in 10.3 as a testbed for the technology, specifically so that it could be incorporated into the iPod-hosted Home technology. I would not be surprised, in fact, if FileVault were to be required for this.

That's it: FileVault is the missing link, not a filesystem database. The rest can be accomplished entirely via technology which has existed in OSX since The Very Beginning, but has yet to acquire a good interface.

[TimmyDee51]

Originally posted by Millennium:
Actually, this could be done by scrubbing the NetInfo database for all users' Home folders. This would probably be faster, considering that most users in the NetInfo database don't actually have Home folders, and so it would be easier to do this than scan the whole disk (or even a index of the whole disk).

While this is true, I have a lab of Macs that have two accounts on there. If a student brought their iPod in and wanted to use their home directory on it, they would have no record in the NetInfo database, rendering it useless in this case.

This capability already exists within OSX. The only thing lacking is an interface to any of it, but your idea of homedirs on a remote computer can be accomplished via NFS, while the iPod thing takes a small amount of NetInfo-wrangling but nothing too major.

This is true, but at the same time, those remote home directories tend to reside on a known server, with a known name and known IP address. This info is entered into the NetInfo database and essentially becomes a static mapping. The issue with the Home on iPod would be the ever-changing target of that mapping. I see two ways of surmounting this -- a file that hold a "static" name for the iPod that NetInfo or LDAP can point to or a bit in the file system that identifies this as a potential home directory and thus grants the user a space in the login window.

Beyond this, I can see issues with permissions. The iPod user would have to be placed in a special group or automatically assigned a group based on preferences set by the administrator. Thus the user would inherit the same preferences as a "normal" restricted user. I'm sure Apple has/is/will be considering this, but it seems like a hurdle to me.

That's something which could be accomplished via FileVault. It's possible that this was included in 10.3 as a testbed for the technology, specifically so that it could be incorporated into the iPod-hosted Home technology. I would not be surprised, in fact, if FileVault were to be required for this.

That's it: FileVault is the missing link, not a filesystem database. The rest can be accomplished entirely via technology which has existed in OSX since The Very Beginning, but has yet to acquire a good interface.

I agree that FileVault is a missing link and should be required if we are to carry sensitive data around in something as palmable as an iPod. However, I'm not sure how I see it solving the problem of getting the file system to recognize a dynamic mapping.

[Bouba]

Netinfo and UFS sure can do the job right now if you have a system that is static. But what I was talking about it the ability to use your own account on a computer that you've never used before without reconfiguring that one. As mentioned above, you would probably inherit the "normal" account privileges until you are granted authorization by an administrator to use your "real" access to the machine.

The reason why I see this as a flag on the file is to increase the speed required to look for these home folders. If these were not present, os X would have to scan, and scan and scan for alternative homes which would render the lookup really slow. That is why we need a database-like filesystem - this is where we are going anyways!

[Rainy Day]

Originally posted by Bouba:
Symbolic links are not the same, they refer to the path of the file (they are similar to the shortcuts in windows) you move/rename the file and they break. This is something that we should fear as mac users. HFS allowed us since (well... since a long time!) to be able to have alias pointing to any file. Modifying the name or the place of that file changed nothing: the alias was still good (except in some weird situation or if the file was moved across partitions.

I said links were similar to, not the same as, aliases. And actually you can rename any link, just like an alias, and you can even move a hard link and it will still resolve; only symbolic links use the pathname. Unfortunately hard links cannot be applied across filesystems, or to folders, so aliases have an advantage here. Hard links are superior to Mac aliases in some ways because there is no difference between the link and the original file. You can even delete the original file, but the data remains until the last link is deleted.

Links and aliases are different (yet similar) critters; each have their own advantages and disadvantages. Aliases are very much like symbolic links, except that they use fileID's instead of pathnames, which has the advantage that they can be readily moved about, but has the disadvantage that the alias will break if the file is replaced (rather than modified) with another file of exactly the same name.

Btw, UNIX links were around decades before there was a Windoze OS.

But aliases and links are moot because you can mount a volume anywhere you want on the directory tree. All permissions issues, etc. that you're talking about go away. About the only limitation to this approach is that you cannot make a hard link across file systems, so you cannot hard link a file somewhere within your home folder and the rest of the file system, or vice versa.

[stew]

Originally posted by Rainy Day:
[B]Actually, the way UNIX filesystems work, this is all trivial because you can mount an HD (or partition) anywhere you want on the directory tree (e.g. at your home directory). In fact, there really is no such thing as separate volumes under UNIX, at least not in the Macintosh sense. The MacOS X Finder gives the illusion of separate volumes on the desktop, but the BSD layer simply see's them as folders inside /Volumes

Which has disadvantages on its own. Treating volumes like directories may make things easier for developers, but it doesn't match any users's mental image - because volumes are not directories.

Example:
I keep my mp3 collection on a bunch of DVDs. I add all these DVDs to my iTunes library (not copying to the hard drive), so that I have an overview of my collection even when I don't have the disc inserted. What happens when I click a song? iTunes in OS 9 correclty asks me to insert the volume called "DVD#2", because it knows that a path starting with DVD#2: refers to a volume. iTunes on OS X instead gives me a stupid dialog telling me that it's unable to find the selected file, because it is unable to tell that /Volumes/DVD#2 is not supposed to be a directory but a volume.

Abstracting things can be nice sometimes, but in places like these it just doesn't make sense. A volume is not a directory, and software should behave accordingly.

[Rainy Day]

Originally posted by stew:
Treating volumes like directories may make things easier for developers, but it doesn't match any users's mental image - because volumes are not directories.

The UNIX way is no more abstract nor less intuitive than the volume oriented approach of HFS. We're just more familiar with the volume oriented approach, so it may seem more intuitive or natural to us. If we had learned the UNIX way first, the volume oriented approach would seem unnatural and cumbersome to us.

Be that as it may, in UNIX, there is no such thing as a volume (at least not in the sense you're thinking). Everything is located somewhere in the directory tree off of the root directory /

That's just the way it is in UNIX, and there are advantages to this approach. Now MacOS X mounts HFS volumes in the /Volumes directory and creates the illusion of volumes (in the sense that you're thinking) in the Finder. MacOS X app's (and AppleScript) have the option to treat them just like volumes in the classic MacOS way (using HFS volume references), or as POSIX paths in the UNIX way.

Take the "volume" away from MacOS X, and it behaves just like any other volume under MacOS 9, for example, regardless of how it may have been accessed under MacOS X.

I don't use iTunes much, so i can't really speak to the specifics of your example, but there's no technical reason why the MacOS X version of iTunes shouldn't be able to deal with this in a more transparent way than you describe. If it doesn't, it's because the programmers didn't think about it, didn't want to do the extra work to support it, or their managers didn't approve it.

[Bouba]

You're right about your exemple with itunes. It's the kind of stuff that needs to be fixed.
The kind of details that makes a system user friendly. I understand the basis that every drive under unix are located under the / but that shouldn't limit the user or confuse the user with strange error message.

[stew]

Originally posted by Rainy Day:
The UNIX way is no more abstract nor less intuitive than the volume oriented approach of HFS. We're just more familiar with the volume oriented approach, so it may seem more intuitive or natural to us.

Nope, it is a natural approach. I have a CD, physically separate from the iBook's internal hard drive and again separate from my external firewire drive. Merging them all in one hierarchy is an unnatural abstraction.

Be that as it may, in UNIX, there is no such thing as a volume (at least not in the sense you're thinking). Everything is located somewhere in the directory tree off of the root directory /

Even worse, in the "everything is a file" approach, devices like keyboards, mice and even graphic cards are mapped to the file tree. They are not files, and they should not be presented as files to the user.

That's just the way it is in UNIX, and there are advantages to this approach.

Which would be?

I don't use iTunes much, so i can't really speak to the specifics of your example, but there's no technical reason why the MacOS X version of iTunes shouldn't be able to deal with this in a more transparent way than you describe. If it doesn't, it's because the programmers didn't think about it, didn't want to do the extra work to support it, or their managers didn't approve it.

To me, the Mac was always about taking that extra step to make things a bit more user-friendly.

[skio]

What about SGI's XFS which is coming to OS X this summer, anyone think that Apple might be making the move to it?

[JNI]

Originally posted by stew:
Even worse, in the "everything is a file" approach, devices like keyboards, mice and even graphic cards are mapped to the file tree. They are not files, and they should not be presented as files to the user.

quote:
That's just the way it is in UNIX, and there are advantages to this approach.

Which would be?

Not to get in the way of your fun little debate here, but keyboards, mice and graphics cards are *not* presented to the Mac *users* as files. First off, the /dev tree is hidden to the normal user. And to the normal user, they are presented as... keyboards, mice and graphics cards. They are presented to *programmers* as files. And there is a huge value in that. If you don't understand the power of abstract FILE streams, then you wouldn't understand what the value is.

To me, the Mac was always about taking that extra step to make things a bit more user-friendly.

That is exactly what they have done. They present the volumes to the user as... separate volumes. Again, the /Volumes tree is hidden from the normal users. And to programmers, they are again, available in a way that works well for them. When a user mounts a remote NFS volume, there is generally no need for the programmer to treat it any different than if it were a part of a monlithic filesystem.

The fact that iTunes doesn't handle the case where a volume is currently offline has nothing to do with Unix. The iTunes developers just didn't handle the case well.

And now, back to your regularly scheduled religious debate...

[Rainy Day]

Originally posted by stew:
Nope, it is a natural approach.

In your opinion. But this is all relative and there are no absolute truths here.

I have a CD, physically separate from the iBook's internal hard drive and again separate from my external firewire drive. Merging them all in one hierarchy is an unnatural abstraction.

Unnatural to you, perhaps, because you're accustomed to the volume metaphor. But the volume metaphor is just as much an abstraction.

Panther comes on three CD's. But isn't Panther the collective data on all three volumes?

Originally posted by Rainy Day:
there are advantages to this approach.

Originally posted by stew:
Which would be?

There are many. Here are a few just off the top of my head:

• The ability to keep your home folder on an external drive which you can easily move from machine to machine.
  
• Increase performance by using separate drives for key regions of the filetree. For example, the swap space might have it's own drive, the system area another, the user area another, etc.
  
• The ability to use the same home folder for several different boot partitions (each partition might have a different version of the OS; e.g. one for Jaguar and one for Panther).
  
• The ability to augment the applications folder of a machine you happen to be visiting with the applications contained on an external drive you bring with you. This can be done using a union mount. While the union is in place, files from both disks are available for use, but when the union is broken, the applications you brought with you leave with you too (because no applications were copied to the host HD). This is a big portability boon for road warriors.
  
• The ability to seamlessly add capacity to your filesystem without the inconvenience of dealing with volumes. This can save you from having to reinstall the system on a larger drive and copy a bunch of files (because the new drive augments the old drive).
  
• Another advantage is the ability to place quotas on individual sections of the filetree. This might be done for security reasons, especially if your running a server, or for convenience. For example, you can segregate the system area of your filetree from your workspace, preventing movies, for example, from filling up your drive and bringing the system to it's knees cause it can't write to the swap space or log files.

This is only a small list. Many more things are possible.

Granted, you can do some of these things with a volume based filesystem, but often only with great effort, usually not seamlessly, and often it isn't very robust.

To me, the Mac was always about taking that extra step to make things a bit more user-friendly.

Well, okay, i agree with this statement, but what's your point? MacOS X supports the volume metaphor. Your complaint about iTunes is really an iTunes issue and not a POSIX vs volumes metaphor issue (because iTunes could be written differently to avoid that issue). Actually, i suspect you might be able to solve your iTunes issues with the appropriate use of Mac style aliases, but i don't know.

[stew]

Originally posted by Rainy Day:
Another advantage is the ability to place quotas on individual sections of the filetree. This might be done for security reasons, especially if your running a server, or for convenience. For example, you can segregate the system area of your filetree from your workspace, preventing movies, for example, from filling up your drive and bringing the system to it's knees cause it can't write to the swap space or log files.

I don't see how quotas are related to a non-volume oriented approach.
All the other points your mentioned can be just as well solved with symbolic links in a volumeoriented system.

Well, okay, i agree with this statement, but what's your point? MacOS X supports the volume metaphor.

The volume-metaphor is a craft-on solution that works only in parts. As soon as you open a Terminal, your are faced with the /-tree. And no, you don't have to be a developer to use the Terminal.

Your complaint about iTunes is really an iTunes issue and not a POSIX vs volumes metaphor issue (because iTunes could be written differently to avoid that issue).

It is a system issue. The dialog that iTunes in OS 9 presents is an automatic system dialog, brought up by OS 9 because a program requested a file on a volume that wasn't insterted. iTunes on OS 9 doesn't know **** about volumes, but OS 9 knows and acts accordingly. OS X suddenly offloads this to the developer and does not take care of itself? So much for advanced operating systems.

[stew]

Originally posted by JNI:
Not to get in the way of your fun little debate here, but keyboards, mice and graphics cards are *not* presented to the Mac *users* as files. First off, the /dev tree is hidden to the normal user. And to the normal user, they are presented as... keyboards, mice and graphics cards. They are presented to *programmers* as files. And there is a huge value in that. If you don't understand the power of abstract FILE streams, then you wouldn't understand what the value is.

Why would you need to put it in the /dev tree when it's only interesting for developers? /dev is visible from the Terminal, and also from the Finder if you use TinkerTool - and you don't have to be a developer to use either of them.

Besides, file streams for input devices? This is the 21st century, we have system messaging and event loops. Why would you want to access an input device via file streams? Feel free to restrict yourself to POSIX forever if you want, but I prefer using modern APIs like NSEvent and don't see why I as a user or developer should bother with such archaic things when I have object oriented goodness.

[dharknes]

Where is the account information stored? It can't be stored in the users home directory. How do I know I can trust that information hasn't been tampered with? How do I know that the person logging in is really the person who owns the account? Anytime you provide public or semi-public access to a computer system you MUST know who and how people are using that system.

Originally posted by Bouba:
Netinfo and UFS sure can do the job right now if you have a system that is static. But what I was talking about it the ability to use your own account on a computer that you've never used before without reconfiguring that one. As mentioned above, you would probably inherit the "normal" account privileges until you are granted authorization by an administrator to use your "real" access to the machine.

The reason why I see this as a flag on the file is to increase the speed required to look for these home folders. If these were not present, os X would have to scan, and scan and scan for alternative homes which would render the lookup really slow. That is why we need a database-like filesystem - this is where we are going anyways!

[dharknes]

Originally posted by stew:
Even worse, in the "everything is a file" approach, devices like keyboards, mice and even graphic cards are mapped to the file tree. They are not files, and they should not be presented as files to the user.

I find it funny the Mac users what Apple to use a consistant metaphor for all user interaction. Which is exactly what Unix provides, if I want to read keystrokes from the keyboard I can just open the /dev/keyboard. If I want to add mouse support I open /dev/mouse. I don't have to worry about any special device commands or access methods. It's called interface consistancy.

Which would be?

Advantages
1) No need to know the details of the structure. I can mix and match filesystems (FAT32, HFS, ISO9660, UFS) and they all work the same.

2) I can easily example the size of directory tree. I just bought a new hard drive for my Linux box I first mounted it as /mnt/temp then copied everything from /home to /mnt/temp then remounted the new drive as /home.

3) I don't have to know where the mount comes from. /User/dharknes could be on my iPod, a firewire drop, a network drive, or my kitchen toaster it doesn't matter.

4) It's easier to tell a user go to /Applications/Adobe/KillerApp then to ask "What volumes do you have?"

5) It's more logically, since everything starts at / and goes down the tree.

Disadvantages
1) Mostly has to be preconfigured.

2) Was orginally designed for hard disk, tape, and network transparency, and thus doesn't handle floppies and removable media as nicely as it could.

3) Doesn't map well to the "Mac" or even the "Windows" way of doing things.

[dharknes]

This would certainly be interesting. Many advantages over UFS and depending on how Apple implements it, many over HFS+. Besides the sooner Apple get off HFS and onto a true Unix filesystem the better.

Originally posted by skio:
What about SGI's XFS which is coming to OS X this summer, anyone think that Apple might be making the move to it?

[Millennium]

Originally posted by stew:
Nope, it is a natural approach. I have a CD, physically separate from the iBook's internal hard drive and again separate from my external firewire drive. Merging them all in one hierarchy is an unnatural abstraction.

However, this part of the hierarchy is hidden from the user, and therefore the abstraction used is irrelevant.

Even worse, in the "everything is a file" approach, devices like keyboards, mice and even graphic cards are mapped to the file tree. They are not files, and they should not be presented as files to the user.

They are not, however, presented this way to users. Again, this abstraction is hidden from the user, and therefore irrelevant.

To me, the Mac was always about taking that extra step to make things a bit more user-friendly.

This would be why the Nasty Developer Stuff is hidden from the user. It is a way of making the system both user-friendly and developer-friendly.

[Millennium]

Originally posted by stew:
As soon as you open a Terminal, your are faced with the /-tree. And no, you don't have to be a developer to use the Terminal.

Yes, but you do have to be a developer -or a power-user- to have to use the Terminal. You certainly have to be a developer to grab stuff from the keyboard, at which point the programmer's interface to the keyboard becomes irrelevant.

The Terminal is about as essential to OSX as MacsBug was to OS9. You could use that to peek into the OS internals as well, and yet no one ever complained about MacsBug.

[Millennium]

Originally posted by Bouba:
Netinfo and UFS sure can do the job right now if you have a system that is static. But what I was talking about it the ability to use your own account on a computer that you've never used before without reconfiguring that one.

It is a pretty safe guarantee that this is never going to come to the Mac, or any other operating system. This model has so many inherent security flaws that it would be utter lunacy for anyone to even include it as an option.

The closest you might see would be a network-controlled user directory, such that you could log into any computer on the network with no further configuration. This would be ideal for lab setups, which can currently do something like this but have to rely on network-based storage. A scrub of the user directory would be about the same speed as scanning a filesystem index (which is how a filesystem database would have to store it for there to be any hope of decent performance), but it has the advantage of being compatible with other operating systems. I don't see Apple backporting this to earlier versions of the OS, but I do see them trying to make it compatible with existing Windows and Unix networks.

[stew]

Originally posted by Millennium:
However, this part of the hierarchy is hidden from the user, and therefore the abstraction used is irrelevant.

It's not hidden very well.
Open your system drive in the Finder. Try creating a folder called "Volumes". Or "dev". If it were hidden properly, I would be able to create such a folder. (Similar to the "Trash" thing in OS 9 - bad practice). If you hide it, do it properly or let it be. Otherwise, you get inconsistent behavior and irritated users.

[Millennium]

Originally posted by stew:
It's not hidden very well.
Open your system drive in the Finder. Try creating a folder called "Volumes". Or "dev". If it were hidden properly, I would be able to create such a folder. (Similar to the "Trash" thing in OS 9 - bad practice). If you hide it, do it properly or let it be. Otherwise, you get inconsistent behavior and irritated users.

What are you doing creating folders in the root directory anyway? Last I checked, users weren't allowed to do that, and for good reason. Have you been messing with the system's internals, or logging in as root?

[TimmyDee51]

Originally posted by Millennium:
It is a pretty safe guarantee that this is never going to come to the Mac, or any other operating system. This model has so many inherent security flaws that it would be utter lunacy for anyone to even include it as an option.

The closest you might see would be a network-controlled user directory, such that you could log into any computer on the network with no further configuration. This would be ideal for lab setups, which can currently do something like this but have to rely on network-based storage. A scrub of the user directory would be about the same speed as scanning a filesystem index (which is how a filesystem database would have to store it for there to be any hope of decent performance), but it has the advantage of being compatible with other operating systems. I don't see Apple backporting this to earlier versions of the OS, but I do see them trying to make it compatible with existing Windows and Unix networks.

I fail to see how this would be a security risk. Rather, it would be similar to using a network controlled user directory. Apple could easily set up a separate class of user that would handle iPod homedirs and make it possible for an administrator to restrict or grant permissions to that user. Setting a bit in the file system that identifies possible home folders on the disk would be very useful: it would save the time of indexing or scanning the entire drive.

Just because a user is allowed to customize their own home folder (network, disk-based, or local) does not mean they are granted full access to the system. I don't see any security flaw in this at all.

[stew]

Originally posted by Millennium:
What are you doing creating folders in the root directory anyway? Last I checked, users weren't allowed to do that, and for good reason. Have you been messing with the system's internals, or logging in as root?

Nothing at all. Open the hard drive, create a folder. You don't need to be root or anything, just go ahead and do it. I don't see why the system should be putting such strange restrictions on what I'm allowed to do and what not.

[edit:]Of course, you have to be Admin (not root!) to do that, but since by default you're logged in as an Admin user on a freshly installed OS X, I consider this being normal circumstances.

[TimmyDee51]

I agree that that could be an issue, but certain HDDs in the System 7 days wouldn't let you name the drive ".Sony" or it would be rendered useless. Granted, how many users wanted to name their drives ".Sony", but then again, how many users will create a folder named "etc" or "Volumes". It's just one of those things I guess.

[Rainy Day]

Originally posted by stew:
I don't see how quotas are related to a non-volume oriented approach.

You can't exceed the capacity of the mounted partition. In other words, you can fill up one part of the directory tree without filling up every part of the tree (as in the volume metaphor).

All the other points your mentioned can be just as well solved with symbolic links in a volume oriented system.

Oh really?! I should be most interested to see how you pull off a translucent union with symbolic links.

The volume-metaphor is a craft-on solution that works only in parts. As soon as you open a Terminal, your are faced with the /-tree.

You are pulling my leg on this one, i hope! As soon as you open the Terminal, you are stepping into the land POSIX. I'm sorry, but if you don't know that... or if you want a Mac metaphor, then you really shouldn't be using the Terminal. Nobody is forcing you to use it!

Reminds me of the old Groucho Marx routine: Doctor, doctor! It hurts when I do this! So don't do that!

[Bouba]

Originally posted by TimmyDee51:
I fail to see how this would be a security risk. Rather, it would be similar to using a network controlled user directory. Apple could easily set up a separate class of user that would handle iPod homedirs and make it possible for an administrator to restrict or grant permissions to that user. Setting a bit in the file system that identifies possible home folders on the disk would be very useful: it would save the time of indexing or scanning the entire drive.

Just because a user is allowed to customize their own home folder (network, disk-based, or local) does not mean they are granted full access to the system. I don't see any security flaw in this at all.

Bingo. I totally agree with that answer. If that user is granted guest access to that machine, it doesn't have any modification right to the other users/other files owned by others. Therefore, it's just another user on the computer. If I want to use the home folder of my ipod on a computer that I own, I could plug the ipod in, login with that account then if I want to make modification to stuff that I don't own, the system should ask for an admin password, which is actually the case.

[intastella]

I don't know if this makes sense, but what if in addition to a separate home on iPod account that people could enable or disable, you had a key embedded in your home account that matched a key on .Mac? You would turn on the feature in the .Mac preferences and it would create a key on the .Mac servers. When you connected your iPod to a home on iPod enabled Mac, it would look up your name on .Mac and confirm who you say you are.

I know some poeple aren't .Mac users but that's definitely a feature worth paying for.

[TimmyDee51]

I think that would be the one feature that would get me to pay for .Mac. I kind of hope they don't go that route, but I could see it happening.

[Millennium]

Originally posted by Bouba:
Bingo. I totally agree with that answer. If that user is granted guest access to that machine, it doesn't have any modification right to the other users/other files owned by others.

Not having write access is almost irrelevent, because the user is still granted view rights to files owned by others in most cases (almost anything that the user hasn't specifically forbidden others from viewing, thanks to Apple's default security settings. Aside from being a privacy risk, these files can contain information on how to get greater access.

Therefore, it's just another user on the computer.

And that is previsely the problem.

If I want to use the home folder of my ipod on a computer that I own...

(emphasis mine)

That is a totally different situation. In a case such as this, the user can be set up on both machines, and use the Home folder on the iPod for both of these. This could even be controlled over the home network, so that passwords, groupIDs and such (even Administrator access, theoretically) stay in sync. The tools are all there now, but there isn't a good UI for it yet. That is the last hurdle that Apple will have to overcome.

But the key here is that it must still be explicitly set up by someone who owns the machine. This is a key security feature which absolutely must be maintained. It should never be possible to simply plug in an iPod on a machine you've never seen and gain access to it. At the very least, whoever owns that machine must specifically let it know by some means that you are allowed to access it. The best way of doing this is to set up a user account for you, because there is no way to access the machine without one.

[Bouba]

Anyways, the security of the computer is almost nill if you have physical access to the machine. Just boot in single user mode and you can activate the root password, erase files, consult files, etc.

By default, os X has home folders with view access only, write access in the Public folder's drop box, read access for the sites, but the rest of the folders are all blocked: You can't see what's in there, you can't consult the files and can't therefore guess the admin password or gain administrator function unless you are being granted authorization by the admin of the computer.

It is not any worst than booting from a userdatabase that is store on a server. This system is just to apply the same principle to a small size network or even to a single computer.

And by the way, mac os x default behaviour is to put you in the document folder when you save a file. So you should never save files directly in your ~/ folder. I don't see why this should be an issue on a new computer. Where all the files should be saved in those protected folders.

For your information, they could add a check box that says: enable logging from remote devices and you'll be at peace of mind...

So stop saying that it is a MAJOR security issue when in reality it is not.

[Bouba]

I could also have an entire copy of the system on the ipod and boot from it... and therefore having access to the exact same files in the exact same way with even more privileges (If you had admin privileges)... You won't be able to go inside the other user's documents unless you were the root user (which is possible to do when booting on a system that is yours)

[Bouba]

it's in reality a functional backup, a backup of your main computer that can be consulted with other computer in a better way... (While increasing the security of the data on the ipod) Some people said that filevault would be the missing link here.. it probably is.

[TimmyDee51]

Further addressing the "security" issue here, I'm sure Apple will include a preference that will either allow or deny the Home in iPod function. If you're worried, turn it off. If you are further worried, deny access to your home folder for anyone else via permissions, enable the root user yourself and set the password, and slap an Open Firmware password on the machine. If you are worried about security, Apple gives you options. This isn't MS we're talking about here.

[hudson1]

Ignorant fool here jumping into a very interesting dialogue:

Since a Mac OS X "machine" (as in Root user) knows who the Admin users are for that machine, isn't that the essential security feature that's already in place? In other words, you can't just plug in an iPod with a home directory and have that user declare himself as an Admin of that machine since Root knows ahead of time who the Admin user(s) is(are). Of course, a regular user can gain Root access to the machine once logged in but they would have to know the Root password which is machine-specific. Is there any conceivable way that a normal user can extract that Root password, violating the security of the machine?

[Millennium]

Originally posted by Bouba:
Anyways, the security of the computer is almost nill if you have physical access to the machine. Just boot in single user mode and you can activate the root password, erase files, consult files, etc.

That is true, though you have forgotten the easiest way: steal the hard drive and then put it in your own machine.

By default, os X has home folders with view access only, write access in the Public folder's drop box, read access for the sites, but the rest of the folders are all blocked...

You don't get it: that is not secure enough for something like this to be even remotely sane. For it to be even semi-sane to allow any arbitrary user to access the machine just by plugging in a device that you have no control over, you would have to completely block all user folders. Not only that, but you would have to block all applications as well, since these can be used to obtain information about the machine. Once you've done that, you have just rendered this kind of access useless; you can't manipulate or view your own data (blocked applications) or anyone else's (blocked user folders), so you may as well not be plugged into the machine at all.

That is what security means. Petty "convenience" features are not always feasible. It's not feasible to trade convenience for security in the real world, but it is an absolute necessity to do it when computers are concerned.

: You can't see what's in there, you can't consult the files and can't therefore guess the admin password or gain administrator function unless you are being granted authorization by the admin of the computer.

Under your model, yes you can, yes you can, and yes you can.

It is not any worst than booting from a userdatabase that is store on a server.

Yes it is, because the user carries his own data around with him. That must not be allowed, because it is trivial for a malicious user to modify his own data, or for an intruder to steal it and then use it himself.

If you want your user directory to follow you around, do it over your own network. It can be done right now, and it does not require an iPod. All it requires is a decent interface. That interface has, admittedly, not yet been written, but it would be no more difficult than this exercise in security illiteracy.

This system is just to apply the same principle to a small size network or even to a single computer.

And the small-sized networks are the easiest to hack, and the new favorite targets of worms and spammers.

For your information, they could add a check box that says: enable logging from remote devices and you'll be at peace of mind...

It borders on immoral to include an option which is so innately damaging to a machine's security.

So stop saying that it is a MAJOR security issue when in reality it is not.

Have you ever even studied computer security? It doesn't sound like you have.

[Millennium]

Originally posted by hudson1:
In other words, you can't just plug in an iPod with a home directory and have that user declare himself as an Admin of that machine since Root knows ahead of time who the Admin user(s) is(are).

One, that's not what this guy is requesting. He wants to be able to access any Mac in the world with no configuration, even those he has never seen. In other words, the Mac would have no foreknowledge of him, and that is what violates the security.

Of course, a regular user can gain Root access to the machine once logged in but they would have to know the Root password which is machine-specific.

Not an Admin user. An Admin user can just go into the Terminal and do sudo passwd root, put in his own password, and then set the root password to anything. Why would you need to get the root password when you can just set it to whatever you want?

This is also the problem with the Keychain. If someone can log into your machine, he doesn't even need any password that's stored in your Keychain; he can just go there and use whatever the Keychain has stored. This is why you should never put anything in your Keychain that could theoretically put you in any danger were it to be hacked.

Is there any conceivable way that a normal user can extract that Root password, violating the security of the machine?

By default, no. But keep in mind, the root password is not necessary (it doesn't even exist on OSX machines by default); you only need an Admin password. Those are easier to get at.

[Bouba]

Millenium, I do agree and understand you point of view, and I am trying to find a way how this could be done to avoid the security problems that you mentioned.

I suggested earlier an option to create users without home folders

I got this idea from previous work from apple on rhapsody:

http://toastytech.com/guis/rhapnetmanager.png

Where the admin of the system could maintain a list of users that do not have a home folder in the computer. This would be a way to grant access to the users.

it could be done following 2 different ways:
-Adding user informations that should match the info that is on the device carrying the home folder (if the info on the external hard drive is not the same - the password hash, the username, etc. then this user won't be able to log in).

-from the admin account, in the user pref, the ipod would be detected by the computer but would be greyed out and disabled until an admin grants it the access. Afterward, that user will be able to use the computer.

Imagine that I have access to a computer, but I am restricted to a shared home directory (like a guest account on a public computer) I'm limited because of the fact that I can't modify the prefs, but I'm also limited in efficiency because I have no option to configure my workspace without affecting the others. I accept that I shouldn't modify the system settings but carrying my home folder with my files and settings would be of a great help here. In fact, the files would already be accessible, but not the settings...

This is why I think that this option should be there to be used, maybe not by default, but present anyways.

I think that we should not abandon this idea like you propose, but work with it, play with it, rethink it. It is for sure feasible in a secure way.

[TimmyDee51]

Originally posted by Millennium:
You don't get it: that is not secure enough for something like this to be even remotely sane. For it to be even semi-sane to allow any arbitrary user to access the machine just by plugging in a device that you have no control over, you would have to completely block all user folders. Not only that, but you would have to block all applications as well, since these can be used to obtain information about the machine. Once you've done that, you have just rendered this kind of access useless; you can't manipulate or view your own data (blocked applications) or anyone else's (blocked user folders), so you may as well not be plugged into the machine at all.

What about a plain old FireWire hard drive? That poses even more of a threat because the user can install a full copy of OS X, boot from it, and copy all your files to hack at a later date. Do you lock your computer up when you're not using it? Controlling physical access is the first step in good security. If you don't want someone messing with your machine, don't let them get to it. Second, disable the feature if it makes you nervous. I'm sure Apple won't ship Home on iPod without a way to turn it off.

Not an Admin user. An Admin user can just go into the Terminal and do sudo passwd root, put in his own password, and then set the root password to anything. Why would you need to get the root password when you can just set it to whatever you want?

So don't grant them admin access. Just because a user has admin access on their own computer doesn't mean they have it on yours. Think about what you said earlier about network homedirs. A user can be admin on their own computer but still have access to a network directory. That doesn't mean they have complete control of the network space, does it? The same is true of roaming profiles. The user has complete control of that directory (essentially an admin of that space) but does not necessarily have privileges over the whole machine unless the admin specifies it.

Perhaps security concerns is what is holding it up? Whatever the case, I'm sure it will be as secure an implementation as any give that the person has physical access to the machine and it's FireWire ports.

[utidjian]

Apple/Mac OS X have several problems to begin with...

* Try running:
nidump passwd .
as _any_ user on the system. You will most likely get one or more of the password hashes. Now, for those of you that try it you may get all *** for the password field. Others will get the full password hash. I have no idea why it is inconsistent across various systems even with the same software and updates installed. To those of you who are not aware of this... once an evildoer gets ahold of the password hashes of either the admin user (system owner) or root user... it is only a matter of time before they crack the hash back to the plaintext password. Once that happens your system is, for the most part, _completely_ compromised. All the evildoer needs is login, could be local or remote, or a system sitting there with another user logged in but the legit user went away for a minute or two. It can be done remotely if they have a login. It can even be done remotely with NO regular account, and NO physical access... just takes a little social engineering. Get a legit user to run a script and it will email them the output of nidump. It only takes a few seconds to do. It is NOT enough to just "chmod 0500 /usr/bin/nidump" (and the other NetInfo Utils in /usr/bin). A evildoer can simply bring it with them either copy it remotely or on an iPod or USBdisk.
OK enough on nidump for now... there are plenty of other problems with it though (as you can probably tell it is one of my main concerns).

* What is it with this "Repair Permissions" thing???!!???
No other Unix or Linux I have ever used has needed such a thing. Yes, it could be a problem for other Unix systems. Most any Unix (I also mean Unix-like systems when I say that) system requires that software be installed by a user who is or can be elevated to UID=0 (root) and an installer with UID=0 privs can do whatever it wants. Yet all the other Unixes and their application builders seem to get it right. Apple has to get developers in line... so that their application installs do not run amok over the filesystem screwing up permissions in the first place. The Mac should flatout refuse to install an app that does not do it correctly. One shouldn't have to "repair" a system after simply installing an office suite or an IM client or whatever. The Repair Permissions utility only (and hopefully, correctly) repairs things installed from Apple. Run the utility several times in a row and it still seems to come up with perms that need fixing.

* HFS+ is a nice file system. In many ways, for a stand alone machine and for "user-friendliness", it is superior to the other alternatives. But few machines are stand alone any more. Even a laptop is going to network with other systems once in a while. Other systems are going to network to a Mac. People may want to plug their iPod (or whatever) into a Windows box or a Linux box or a *BSD box and use it like any other disk. Apple should move to a filesystem that everyone can read and write to without some kludgy translation wrapper.

* Physical security:
I think Apple has to fix the above problems BEFORE allowing anyone to just plug in an external device and get user permissions on a machine.
It is fairly easy to make it very difficult though, obviously, not impossible to make a box secure even if they do have physical access. Schools and colleges have to deal with this problem all the time. The box is usually physically locked with some sort of cable lock. Apple provides lugs and doohickys for doing exactly this. Set the OF password and the it is impossible for the evildoer to boot from foreign media without destroying the lock or the case. Most schools find this level of physical security to be enough.

With all that said... I think the idea of being able to do just that is pretty cool.

[JLL]

Originally posted by utidjian:
Apple/Mac OS X have several problems to begin with...

* Try running:
nidump passwd .
as _any_ user on the system. You will most likely get one or more of the password hashes. Now, for those of you that try it you may get all *** for the password field. Others will get the full password hash.

That was how NetInfo in 10.0-10.2 worked. You shouldn't see anything but *** in 10.3.x. And NetInfo is on it's way out btw.

Originally posted by utidjian:
* Physical security:
I think Apple has to fix the above problems BEFORE allowing anyone to just plug in an external device and get user permissions on a machine.
It is fairly easy to make it very difficult though, obviously, not impossible to make a box secure even if they do have physical access. Schools and colleges have to deal with this problem all the time. The box is usually physically locked with some sort of cable lock. Apple provides lugs and doohickys for doing exactly this. Set the OF password and the it is impossible for the evildoer to boot from foreign media without destroying the lock or the case. Most schools find this level of physical security to be enough.

I don't know what you mean here - are you implying that Apple should set an OF password by default?

[utidjian]

Originally posted by JLL:
That was how NetInfo in 10.0-10.2 worked. You shouldn't see anything but *** in 10.3.x. And NetInfo is on it's way out btw.

Yes. But I still see the password hash on some systems... even with NetInfo unchecked in Applications --> Utilities --> Directory Access. This is on 10.3 systems. Some show it as all *** some don't. (shrug)

I don't know what you mean here - are you implying that Apple should set an OF password by default?

I think there should be an option to set the OF password depending on how the machine is to be deployed. For the most home users this isn't neccessary but for those of us that are running labs full of Macs it is.

My point is.. physical access to a machine isn't as much of a security problem for issues that require physical access. It is fairly simple to just use an OF password and a physical lock to prevent unauthorized use of the machine.
On the other hand the remote access and local login is far more difficult to secure with the current state of Mac OS X security.

[utidjian]

Originally posted by JLL:
That was how NetInfo in 10.0-10.2 worked. You shouldn't see anything but *** in 10.3.x. And NetInfo is on it's way out btw.

Yes. But I still see the password hash on some systems... even with NetInfo unchecked in Applications --> Utilities --> Directory Access. This is on 10.3 systems. Some show it as all *** some don't. (shrug)

I don't know what you mean here - are you implying that Apple should set an OF password by default?

I think there should be an option to set the OF password depending on how the machine is to be deployed. For the most home users this isn't neccessary but for those of us that are running labs full of Macs it is.

My point is.. physical access to a machine isn't as much of a security problem for issues that require physical access. It is fairly simple to just use an OF password and a physical lock to prevent unauthorized use of the machine.
On the other hand the remote access and local login is far more difficult to secure with the current state of Mac OS X security.

[JLL]

Originally posted by utidjian:
I think there should be an option to set the OF password depending on how the machine is to be deployed.

There is: http://docs.info.apple.com/article.html?artnum=120095

[Millennium]

Originally posted by TimmyDee51:
What about a plain old FireWire hard drive? That poses even more of a threat because the user can install a full copy of OS X, boot from it, and copy all your files to hack at a later date.

Only if the user manages to first gain access to the machine by logging in.

That's just it. The problem is not with storing a homedir on an iPod; the problem is the ability to automatically give yourself access -even if it's not Administrator-class access- on any Mac, even ones that you don't own.

For the last time, I am not in any way disputing the idea of a user having his home directory on an iPod. I don't see any use in it that isn't done just as well (if not better) by networked homedirs, but it doesn't compromise security.

The ability to grant yourself access any machine without having the machine's owner explicitly grant you access to it by giving you an account, however, is quite possibly the single worst idea in the history of computer security. It is insane on a scale that even Microsoft has never managed to achieve.

[Millennium]

Originally posted by utidjian:
Apple/Mac OS X have several problems to begin with...

* Try running:
nidump passwd .
as _any_ user on the system.

Most Unices have a problem similar to this, in the /etc/passwd file. This must, by design, be readable to any user on the system, because it stores important information that many programs need.

The standard way of getting around this is called shadow passwords. With this system, /etc/passwd doesn't actually contain password hashes; it just includes a placeholder. The actual hashes are stored in a file (usually /etc/shadow) which only root can read.

Apple did not, for some inane reason, support shadow passwords until 10.3. Fortunately, that hole has been patched up now.

* What is it with this "Repair Permissions" thing???!!???
No other Unix or Linux I have ever used has needed such a thing. Yes, it could be a problem for other Unix systems. Most any Unix (I also mean Unix-like systems when I say that) system requires that software be installed by a user who is or can be elevated to UID=0 (root) and an installer with UID=0 privs can do whatever it wants. Yet all the other Unixes and their application builders seem to get it right. Apple has to get developers in line... so that their application installs do not run amok over the filesystem screwing up permissions in the first place. The Mac should flatout refuse to install an app that does not do it correctly. One shouldn't have to "repair" a system after simply installing an office suite or an IM client or whatever. The Repair Permissions utility only (and hopefully, correctly) repairs things installed from Apple. Run the utility several times in a row and it still seems to come up with perms that need fixing.

Agreed; this is a severe problem for OSX as we currently know it.

There is a major problem with fixing this, though. OSX currently has no way of knowing when the permissions on a file have been changed, except to check its permissions against some predefined value that should be there. Because programs are installed as root, the only way to really block this would be to run installers in a special sandbox-type area which adamantly refused to change the permissions of existing files.

Granted, Apple should get cracking on this. It's frankly imperative that installers be run in an environment that the user can trust not to screw things up, even if it means limiting the potential power of installers.

* HFS+ is a nice file system. In many ways, for a stand alone machine and for "user-friendliness", it is superior to the other alternatives. But few machines are stand alone any more. Even a laptop is going to network with other systems once in a while. Other systems are going to network to a Mac. People may want to plug their iPod (or whatever) into a Windows box or a Linux box or a *BSD box and use it like any other disk. Apple should move to a filesystem that everyone can read and write to without some kludgy translation wrapper.

There is no such filesystem, except maybe FAT16, which is woefully inadequate.

The specs for HFS+ are completely open. Anyone can implement it, if they so choose; in fact, implementations already exist for Windows, Linux, and even BeOS. Linux support is offered with the kernel, and BeOS support has been in since The Beginning. The only implementations out there for Windows are currently commercial, but that could easily change. As long as Apple makes itself interoperable with other filesystems (via, for example, the translation layer), it is under no obligation to use those filesystems itself.