UUIDs - permissions, security, changes, etc.

UUIDs get used a lot, but the way they get used varies. Some of these variations are surprisinig, and represent reliability or security risks if the programmer doesn't understand them. I don't claim to understand more than that these subtle issues exist, and I haven't found any summary on the wiki. So here are some UUID issues:

The UUID for an AV will never change. UUID for objects, and presumably individual prims, can and do change. What about textures, scripts, notecards? Are there situations where you can be sure that the UUID for an object won't change (ignoring bugs and and changes by LL)? Does editing a notecard or script change it's UUID? Moving or copying in or out of object inventory? Move a script from one prim to another? Give a (no-copy) notecard or script to someone else?

With just a UUID, you can send IMs to an AV, determine whether or not it's logged in, and various other things. Since the UUID is readily available, there ought not be any security risks associated with publishing an AV's UUID. In other words, there's no point in trying to keep it secret. Whether there are any such risks is a different question.

Here's the one I find interesting: Witih just a UUID, you can read a notecard or apply a texture. How do permissions fit in? Apparently I can read a notecard or apply a texture with just a UUID, whether or not it's in the sim or user's inventory in any way. Do I need permissions? Or does knowing the UUID for a notecard or texture allow you to violate no-transfer, and effectively no-copy/no-mod for these? What about scripts?

Are there clever ways to exploit these properties of UUIDs? One thought is that if a notecard keeps its UUID on edit, then you could make a global configuration change to a large set of objects by simply having them read that notecard for updates. But if there's no way to change a notecard without changing the UUID, then this wouldn't work.

Am I missing any other issues around UUIDs?

For the sake of expediance I will mix the terms key and UUID, they are the same thing.

In general UUIDs never change but new instances are issued new keys.

Rezzed objects (attached or not) have instance keys assigned to them. Instance keys are assigned when the object is rezzed. Each prim has it's own instance key.

All assets that have an asset key. When an inventory item is modified it is assigned a new asset key. The old asset is only garbage collected on the asset server if it can be proven orphaned. Changing the assets properties in inventory (with the properties dialog) does not cause the creation of a new asset.

There are avatar UUID libraries. There is even a LibSL example bot that just does name2key searches. Accentually there isn't much of a security risk in publishing AV UUIDs, sure you can see if they are online, but not much else.

The permission system is built on the inventory system, the asset system is the layer below the inventory. Using UUIDs in scripts sidesteps inventory permissions. This is a serious concern and thus far has gone largely unexploited. The main reason is that is detectable. It's not hard for LL to find which object use a UUID or who wrote the script in question that is facilitating the theft. The data has to be uploaded somewhere and that somewhere has a logfile attached to it.

----

The main thing I use UUIDs for is with notecards. Have a number of slave prims all with the same script except each known which line to read. Then send a link message to the set containing the notecard UUID. Each script executes its line of instructions simultaneously.

If you want to write a wiki article on this you have my permission to reuse any of this post.

wellll....

according to the age-old answer to "why can't scripts write to notecards?" they can't because writing to a notecard would create a new asset, and scripts aren't allowed to create new assets.

so i interpret this to mean that every time you edit or save a notecard, it gets a new key. is that right, strife? if it doesn't get a new key when i do this, then um... dare i ask why scripts can't write to notecards?!? :X


so, for example, if i make a vendor that reads inventory info from a notecard, and i use ONE notecard in my inventory for it to scan.... thinking i can be clever and just update my notecard here in my pocket and have all my vendors then use that new information.... the vendor looks for the uuid i gave it, and then cant' find it after i've edited it?


here's a scary question... do uuids ever get reused? if the asset server prunes them?


this concept just makes my head hurt.

I'm not sure I can see a case where someone could use a UUID for something they have no right to. To get the UUID of an asset (sound, texture, animation) you have to have full perms on that asset. If you have a full perm copy, you have the rights to use it, technically. The only way you could get a key for say, a no mod/no copy animation, would be if the creator gave it to you. Even then, you can't play animations by key from a script. So I guess I don't see this security hole you say exists. Wether scripts sidestep inventory perms or not is largely moot, as you have to use the inventory system to get the key in the first place. Even if you have the key, you are often severely restricted.

I'm guessing they don't reuse. according to the wiki:

"There are 2^128 possible key combinations, yielding 340,282,366,920,938,463,463,374,607,431,768,211,456 possible keys."

since they have so many, I see no reason they would have to reuse keys.

Correct
A new UUID will be issued when the notecard is modified, the old UUID will still work; see my comment about garbage collecting. When you edit a notecard it just updates the specific instance of the inventory handle, not all instances of the inventory handle.

Example:
Notecard A is an inventory copy of Notecard B.
Update Notecard A.
Notecard B will not point to the new version of Notecard A (regardless of where Notecard B is)

This is not true at all. Assets are identified by UUID. When you look at a picture, how does your SL client know what texture to download?

Hint: http://img370.imageshack.us/img370/8449/picture3fb8.png

And that's a very large number... I think we figured once there could be a UUID for every grain of sand on the planet.

When I was still kinda new to SL, I built a 50-prim texture wall and tried to see what I could 'fish' out by way of randomly assigned texture UUIDs. I built a random UUID generator, and after recalling somewhere between 20,000 to 50,000 textures (yes a lot of clicking)... I never saw anything more than "Missing Image".

I believe that Darien was more meaning that to use such texture by referring to it by UUID, your avatar must have full-perms. I've seen this security in function many times, as often people attempt to reference a texture they own (but do not have full perms to) by UUID in their scripts in an attempt to texture a prim. It simply doesn't work. They then come to me and ask why...and the answer is always the same--they don't have full perms, and therefore don't have permission to use the texture by reference.

This is incorrect. So long as a valid texture key is passed to llSetTexture, the texture will be applied, regardless of who has what permissions on it. No, you can't get the key of an asset to which you don't have full perms via the "front door" (i.e., through the SL client), but there are other ways to obtain that information.

OMG, no wonder the Asset Servers are overwhelmed! Unless I'm missing something, this would mean that every time a vendor pages, a dozen logfiles have to be checked or updated. Is that really the way it works?

The reason why scripts cannot write to notecards and never will be able to do is because of the way asset creation works.

it is, matter of factly, a very complex process.

If you now allow scripts to write to notecards... imagine many scripts doing it at the same time, mayhaps multiple times, on the whole grid.

This would create a FLOOD of asset creation requests. A load which the servers would struggle to keep up with.

If you are interested in further details, you may want to attend Zero Lindens office hours and ask him for a better explanation.

hmmm 4 terms now: key, UUID, instance key, asset key. Sounds like instance key is different from the key and UUID, for sure. What about asset key? Is that a synonym or something else?



What does orphaned mean in this context?



This is a very interesting idea. I think it was you who mentioned it just a few days ago as well. Couplo questions:

(1) You mention link message. Does that mean it will only work with linked objects? What if the slave prim is not meant to be attached? And if it can be unattached, can the slave prim be anywhere in SL?

(2) What if you make something - a whatsit - that uses this read notecard by UUID method, and give say 10 copies of it out. Do all 10 people's whatsits all read from your original notecard, or does the notecard in what you give out acquire a new uuid.

(3) If the notecards in their whatsits do all get their own UUIDs, then I guess you need to make the UUID dynamic by using llGetInventoryKey() or something, and pass it to the slave prims.[/b]

wow squirrel, certainly sounds as though it doesn't bode well for the future in terms of scalability.

But in terms of writing data somewhere, since notecards aren't possible, I'll sure we all have our fingers crossed that they give us *datacards*, or *something*. Setting up an off-world website to store the fact that someone like blue things seems a bit like having to open up the kitchen at the Ritz just to make a baloney sandwich.

You are advised to use off-site storage. either your own mysql server or other means.

heyas;

strife, im still having trouble visualizing it. do you mean something like this:

notecard A = id1

copy notecard A to notecard B

notecard B = id2

edit notecard A

notecard A = id3


...?


so if i edit and save notecard A 10 times, i get 10 new asset id numbers?

what about scripts? everytime i edit and save a script, does IT get a new uuid? you sure they're not gonna run out, cuz i save scripts a lot of freakin times while im working on it (and trying to get the bugs out of it). and i save multiple copies of my objects im working on. oh, and i make multiple copies of clothing bits and attachments every time i save a new outfit. or customize an avatar look.

sure umpteen gajillion numbers are more than any computer system could ever use! so is 16k of memory. ;X

10 new assets may be generated but unless you keep copies of all versions, only the last one will be kept around.

Asset garbage collection will see that the previous versions aren't referenced by anybody any more and delete them. If you were to create 10 versions and put the key of each version into, say, a script, the garbage collection process should see that something still has a reference to each version and it won't clean them up.

Ah, so set up a server to track that someone likes blue things.

The first part is true. However, as I thought I clearly stated, you can not get the key in the first place unless you have full perms to the texture. Using "back doors" was never in the conversation. The only backdoor concerning texture i'm aware of gives you the actual texture, which you would have to re-upload, you still wouldn't have the original key.

By the way, did you know Linden Lab sponsored the production of a step-by-step How-To guide on how to use said texture grabber? Ironic, isn't it.

There are other ways but I suggest we avoid those kinds of topics...

No, notecard B still has id1. (That is, assuming you actually copy the card, as opposed to creating a new card and copy/pasting the contents) Edit notecard A, and it will now have id2, but notecard B will still have id1.

Your inventory doesn't actually contain assets (notecards, textures, sound clips, skins, clothing items, etc...), only pointers to them, based on the asset's UUID. So when you create a notecard, you create a new asset, and a pointer to it is added to your inventory. When you "copy" that notecard (including giving copies to other avatars), you're just creating a new pointer to the same asset, instead of a whole new copy of the asset. So initially, the notecard A and notecard B items in your inventory are just pointers to the same asset. When you edit and save one of them, a new asset is created, and the inventory pointer re-assigned to it.

This system saves gobs of space on the LL asset servers, since thousands of agents can have copies of a given asset in their inventories, without needing to store thousands of redundant duplicates of that asset.


Yup, but garbage collection will eventually free up for re-use the UUIDs of your intermediate card edits, which your inventory no longer contains pointers to and no script references. So no, we won't run out of availible UUIDs.


Yup. Same as above. Scripts are actually two components, the compiled bytecode, and the uncompiled source code, but I believe both have the same UUID. I have a few perfectly functional scripts in my inventory which I can no longer edit, because their source code assets apparently got garbage-collected by mistake.

Once the texture is loaded in your client, it's UUID resides on your hard drive in stupifying prominence, far easier to retrieve than for any other asset. You need only know where to look.

I wonder if that means then that Strife's idea is good only for something you make for yourself -- if you made something with a config notecard that you then gave away to a lot of people, if you relied on a hard-coded notecard UUID it would stop working... would it be that the copies of the config notecards would retain the original UUID for a while, but then eventually that original number would be purged from them?

A given "version" of a notecard should retain a constant UUID, so giving away a script which reads from a notecard referenced by a hard-coded UUID should still work, and "copies" of the notecard (pointers to the notecard data, actually) wouldn't even be necessary. But hard-coding a notecard UUID into a script defeats the purpose of using config notecards, since that key will always refer to "static" data, which itself could have been hard-coded into the script in the first place. You need to have some way of updating the notecard UUID in the script when the card is edited, which creates a new notecard with a new key.

I was more concerned with the social engineering holes. People who make textures don't necessarily know scripting or UUIDs, and might be duped into giving out a UUID.

Or a new scripter might give you a public script that contains a hardwired reference to a protected textures, thinking that the rest of the permissions system will protect it.

All the other points being made are valid. This just happens to be where I was coming from in posting the question.