Do I really? It's a good think I have you to tell me that, isn't it?
8-]
> First of all, performance is extremely important;
> access checks on files is something which happens often and needs to
> happen quickly, so grovelling around in a resource fork looking for the
> ACL is not a good idea.
And I thought it was a wonderful idea. Perhaps before you close this
point and go onto the second, you could explain how to look without
grovelling around somwhere.
> Secondly, ACL's are often duplicated; it will
> be very common for all of the files in a particular source tree (say,
> everything under /usr/src/linux for example) to have the same ACL.
This is not implausible, but imagine a server at an ISP or a University.
It might have lots of different accounts with people setting different
ACL's. Would this approach scale well? Shall we have another standard
error value like EACLTABLEFULL?
>
> So a better way to handle ACL's is to have an ACL's defined by ACL
> numbers, and to store ACL numbers in inodes. The ext2 kernel code would
> maintain an in-memory ACL cache so that when it is doing access checks,
> it can do so very quickly.
Where in an ext2 inode would you put this ACL number? Can we really
do this in an ext2 filesystem or would be have to invent a new one?
If we have to invent a new one, shouldn't we try to get more from
all the trouble we would have to go through?
Also, Have you taken a look at the Orange Book lately? There is
some value in letting Access Control be dependent on sets of tags
that can be used to mark data as tainted in some way, and to let
this tainted condition carry over to data that are modified by a
process that reads this tainted data. Such a system is required
for some kinds of classified work (albeit at the extreme end).
In addition, if we are opening this file, there's a good chance
that we'll be accessing blocks anyway, right? As long as we stick
to the usual cycinder group method of accessing data blocks, the
blocks for the resource forks will be near the blocks for the
data fork (and perhaps near the blocks we just read for the
directory), anyway. While your point about the cost of reading
a block for ACL data is a good one (all joking aside), your own
approach has some additional complications that you haven't
mentioned in this reply, at least.
You won't get a community of non-administrator users to
go out of their way to tell the OS that it can use a
common ACL table entry for all the files that really
have the same list. Also, each list has a variable
length, and users may put the list items in different
orders, so you will have to normalize the order to
get the commonality that you want. And then you have
to index the ACL array (unless you want to do an unindexed
search through an array of variable length lists, each time
you change an individual access control list). All this is
possible, but each additional level of complexity reduces
any advanges that it has over the resource fork approach.
> For things like adding support for the privilege/capability masks for
> executables, yes, the plan was to add a generic capability for storing
> kernel-specific metadata, since that data does not need to be accessed
> nearly as often. (However, for commonly used executables we will still
> want to cache capability masks.)
>
> The point has been made (and it is correct) that kernel
> metadata is fundamentally different than user metadata.
> But this doesn't necessarily mean that they two cannot
> be stored together.
>
> An important reason why you don't want to store user metadata and kernel
> metadata in the same place is that kernel metadata tends to be small.
> For example, the capability masks will fit within 20-30 bytes at most.
> In contrast, user metadata could be huge --- spanning possibly megabytes
> of icones, string tables, sound files, etc. On the Macintosh, it is not
> unheard of for the resource fork to be far larger than the data fork.
First, the Mac users don't seem to mind this. Second, why
did you omit the last paragraph of my message?? I said:
> > The point has been made (and it is correct) that kernel
> > metadata is fundamentally different than user metadata.
> > But this doesn't necessarily mean that they two cannot
> > be stored together. If we decide we need to store kernel
> > metadata in the inode (and I realize this requirement
> > may not have been established) we might be able to store
> > some kinds of user metadata in the same facility without
> > an unreasonable degree of additional complication. If
> > an additional type of user metadata would unduly
> > complicate the inode based metadata scheme, would could
> > condemn it to implementation through these external
> > metadata files, without giving up the advantages of
> > inode based user metadata in those cases where it is
> > easy.
You see, I do have the imagination it takes to see how
carried away users can get with their metadata. I
specifically did not argue that all user metadata can
be collected with the kernel metadata. How about a user
meta tag called "mimetype"? This one doesn't usually
take megabytes (although I'm sure Microsoft will,
someday, use megabyte long mimetypes to make up for
some inadequacy of their OS). Suppose the tag name
plus the value can only add up to 255 bytes. We can
easily do something to keep megabyte long metadata
out of a resource fork, if this is, in fact, a good
idea.
>
> This means that if we engineer a solution that allows for user metadata,
> we will need to make a much heavier weight solution that would probably
> involve a second inode. My original design for dealing with the kernel
> metadata required by the privilege/capability masks involved using a
> linked list of disk blocks to store the kernel metadata. This is faster
> (since it doesn't require an inode lookup) and more space efficient.
>
> (Consider what would happen if every file had an ACL, and ACL's were
> stored in the kernel/user metadata inode; then every file would consume
> two inodes, and every file would have at least extra 1k block to store
> the ACL, and a file permissions check would require reading an extra
> inode and then seeking to another block to read in the ACL.)
Where did this second inode come from? The "resource fork" would be
tracked by the same inode as the data fork. If we have multiple
hard links in separate directories to a single file, the file's
inode is the obvious way to get at the metadata. If we put a
pointer to a different inode for metadata in the main data inode,
we have modified the inode, so we already have to invent a new
filesystem type. As long as we are modifying the inode and
inventing a new filesystem type, why not just put the "resource
fork" in the inode, and make that our change. For those files
that need metadata, we would still have to read a block; You're
right about that. But the other approaches have their disadvantages
too.
> If we avoid storing user metadata, we can have a lighterweight, more
> efficient implementation.
I addressed this very point in that paragraph you forgot to include
from my last message. See above.
> We also avoid needing to define a
> non-standard API for storing user metadata, and we avoid tempting
> application programmers to write non-portable code that won't work on
> any other Unix system in the world.
This is simply incomprehensable. In case you haven't noticed,
there has been a certain amount of interrest in user metadata.
There is no widely accepted standard API for user metadata that
I know of. If there isn't currently a standard API, but people
want the feature, doesn't it seem to you that there is a need
for an API? Doesn't this new API need to start somewhere?? Is
there a metadata API standard that you know of that we should
be thinking about as we venture down the road to metadata? If
there is one, we should consider it; If not, this same argument
would apply wherever we attempt to invent the new API. How can
we ever have a new API without putting aside this argument?
Would you rather wait around for Bill Gates to invent the API,
and then try to implement it on Linux and hold your breakfast
down at the same time.
--- L. Adrian Griffis - KE6CSX - adrian@idir.net- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/faq.html