Sometimes it happens when I relog after setting the perms to find them changed. Sometimes it only happens in 1 of the 4 copies of the vendor IW days later. Other times they change while putting in a box or a vendor but stay correct in the inventory.

This is very important to fix because DMCA takedowns don't seem to cover permission bugs.

From what Stroker posted on SC, the DMCA reports were invalid because "Linden Lab could not substantiate that these articles were being sold inworld."

I had to spend one night to check all of my items then, which wasn't exactly fun

I compared the affected items to the copies in my inventory, which still had the perms that I wanted them to have, so they must have changed later on, without me noticing for some time. I don't know what kind of thing could cause something like that, but it worries me.

I'm sorry but I can't reproduce it, all I can say that different kinds of vendors where affected, such as my slx /slboutique sales vendors as well as some simple sales boxes that give away the content of the boxes.

Big problem. I am experiencing this bug NOW.

I have a hair in my inventory, which contains no-copy xcite scripts. And it is FULL PERMS.
I have tested with giving it to someone else, and the contents remain intact and fully functional after transfer, and leaving a fully functional one in my inventory, too.

I'm not entirely sure how this happened, but I can explain the various things I've done with the hair, which should lead to some clues, I hope. I will not post it here, though. I'll wait for a linden to contact me about it. Posting here would be a security risk.

» http://wiki.secondlife.com/wiki/Security_issues

We really want to help but need to know more. Also re-importing this because the old Linden Lab Issue ID was wrong.

I try to place a lot of my objects on nice positions, like 125,10,20 and not 125.023,10.001,20.006

I have seen some of my objects move over time from their initial position.

What is causing them to change position ??? Data should not change unless set to a new value by the one who has permissions to do. After rezzing an object and putting it at a nice x,y,z position, i don't move it anymore. The information is ONLY read by a lot of other SL clients, i don't understand how there can be an update of the row in the database.

Related question: Is there a check if any value has changed before doing an update to a row ? In other words If I edit an object and do not change anything, is a sql update fired to the database? I sure hope not!

Is there a checksum on the data transmitted from the client to the database server and is that checksum verified before updating the database ?

Are related updates to the database in a transaction ? Is there a rollback in case of a failure ?

Related too: The permission field(s) are probably a bunch of bits, why do those bits flip ? And what is writing them back to the database? Is it possible that the owner opens an edit window to an object, doesn't change a thing, but because of data being corrupted (packet loss, memory problems, you name it) before reaching the database (because of the unneeded update statement described above), bits flip over ?

I know, it is much easier to ask these question than to solve them. grins I am in the software development business for over 25 years

Just my 2 cents.

I've sent a lengthy email to the security list, detailing all my experiences with this. I can only hope the cause gets found out soon.

It should be noted that it doesn't make everything in the object full perms, only the whole package. Perms default to what they should be when rezzed, but that's no good, still.

http://web.archive.org/web/20070113223510/http://secondlife.com/knowledgebase/article.php?id=336

(It's also in our Knowledge Base @ http://secondlife.com/support , but I unfortunately can't link directly to the article.)

fact is we need a professionally engineered database that provides the metadata to trace thing out and when such a defect is revealed then all instances of the object and all of it's descendants be removed from the database. and a courtesy message be sent out that the defective object was removed.

guess i will go rerezz everything and repackage everything. looks like it will have to be a monthly exercise. this also means i may give up on renting mall locations as it will be too cumbersome and time consuming to keep applying bandaids to shoddy code results.

The strange thing is, she had the object full permissions, but when rezzing it to the ground, editing it, the object reverts back to the permissions it should have.

I guess this is what happend with many freebies, since many of them have changing permissions when they are modified (they are not resellable anymore)

I have several examples of these items, i could send them if you like

Right click > Properties still show them as full perm for me, and there are no words after (no scripts contained either), buut on rezzing or wearing, Edit box says I cannot mod, and in fact I annot mod them, resize them etc. There are also reports on JEVN of boxes being set no trans, which is a killer for merchants. Since this is probably a different issue (this one is old) I will submit a new ticket.

While it appears to be making perms more restrictive, any perm problem is bad, and we could see perms being lifted, and stuff being open to theft again. As such, the grid should be shut until this is resolved, and I mean properly fixed, not Linden "resolved".

Me and my friends can provide that logs to LL. Would it be some help to correct the problem?

I guess walking through the pile of freebies i have, quite some percetage of them might actually be created by this error.. that is they are full permission, untill they are rezzed.. (also ones without scripts)

Its the same like my stolen item

default
{
on_rez(integer params)
{

if (llGetOwner() != llGetCreator()) {

integer perm_mask = llGetObjectPermMask(MASK_NEXT);
integer perm_mask2 = llGetObjectPermMask(MASK_OWNER);

if(((perm_mask & PERM_COPY) && (perm_mask & PERM_TRANSFER)) || ((perm_mask2 & PERM_COPY) && (perm_mask2 & PERM_TRANSFER))) { llOwnerSay(llGetObjectName() + " has bad permissions..."); llDie(); }
}

}
}

This bug is terrible.. with the current DMCA nothing can be done to stop the spread.. its so very sad... to see an item you spent so much time to create beeing ruined by a stupid bug and the lack of a proper DMCA handling

sad, very sad

On the items I was selling that this happened with, I checked the permissions inside the vendors and they were set correctly. Some of these items were very complex, advanced scripts and others were a lot of custom animations. This cost me more L$ than I can count. As a content creator and SL business owner, this kind of issue, especially when ongoing, is unacceptable.

Basically there is no way to even detect by scripting that an object has fallen victim to this bug/exploit.

I've reported both the full permission problem and the inability to detect that it is full permission in inventory as bugs but no response yet. Help!

I wonder how many of the freebies we have now are created by this bug. I thought Chavos item was a freebie till he contacted me about this.

Makes one wonder

Torley help us please!

I have atleast three individual objects in my inventory, objects that I made myself.
When looking at the permissions in my inventory, only "Transfer" is enabled.
When rezzing or attaching the object, "Allow anyone to copy" is also enabled.

The three objects are somewhat related in that the scripts are based on one another and they all started as copies from one another, but several other objects for which this is also true do not have this permissions problem.

Not so much a "full-perm" bug, but a permissions bug nonetheless. Reporting it to Torley now.

The majority of the reports I've gotten inworld have said something along the lines of, "This happened months ago, but I haven't seen it more recently". While that's cause for concern, I don't want the trail going cold if there is infact an identifiable bug out there which we want to track down and fix.

Please, PLEASE make sure to differentiate this bug from the subtleties of how the permissions system actually works. I've already received a number of reports from people who thought they were experiencing this bug, when infact it was a misunderstanding.... Tijn, might this apply to you? See what said about the "slam bit" in my earlier comment. I wish permissions were more intuitive, but sadly, they aren't yet.

Voting for this.

i hope lindens sort this out - now even Amethysts business is being effected by it. People are selling the object im talking about (wont give full name of it), those selling this item need penalising somehow. its disgustin that someone can steal this way from other peoples business. Making money on other peoples HARD work.

Surely theres something Lindens can do about this... not just sit there reading this (if they even read these postings) and do absolutely nothing about it. how about a fix for the bug for a starters?

1. Was the sim you were in lagging alot (either because of high traffic? or another reason?)

(try to notice the difference between "actual lag coming from the sim", and " videocard-card-lag"

2. Has anyone experienced this bug with an item that was not 'prim based', but texture based? (most clothing/skins are texture based)

It seems easier to tell if prim objects turned full permission, since most seem to have the right permissions being rezzed on the ground

Also, i would like to make it easier for people to distinguish which cases are really 'this bug' and which cases are ' people that dont understand the permission system"

Especially IF items are sold hundreds of times, and only 1 (or maybe a few) people received it full permission, CAN this be caused by people not understanding the permission system? I would say not?

(for the last thing i would like a linden to answer. Torley?

A customer contacted me on sunday and let me know that my couples animation HUD was being handed out full perms. They sent me a copy and sure enough the HUD appears full perms in inventory and can be copied, transfered etc.

The scripts and animations inside the object still have there correct 'no copy' permissions and as soon as the item is rezzed in world, it takes on the correct permissions that were originally set on the prims. The item that is stored in inventory though reads as full perms and can be transfered, copied, attached and put into another objects contents and set for sale withought taking on the correct permissions.

I really wonder how many items are in world like this... maybe as well as fix the bug causing it, its time for a database sweep or somthing to correct these permissions which are not displayed correctly in inventory. I seem to recall something similar was done when a permissions bug occured back in some update.

Please give this issue the highest priority possible.

There is no technical solution possible to protect most "intellectual property". Objects, textures, sounds, animations, will always be fully copyable, and there is nothing anyone can do with technical means to prevent it.

This is not an exclusive problem Second Life has, this is how all digital media is.

This happened each time I rezzed the item. I deleted the offending copies and got a new one from the original box I had kept as backup, which had the correct perms. I didn't try to see if anyone could buy the item but in retrospect I wish I had, it would have been useful to know if a trusted friend COULD buy an item marked no-trans (and then delete it to protect the creator).

And LOL to Tijn Erde's comment of 19/Jan, but showstopper specifically references only those bugs which prevent the user from getting onto or functioning in SL at all. Nobody has to create, although I agree they should be fully supported and protected in doing so! Critical is the correct status for this issue. I notice it isn't making a difference to LL assignment though.

The two sets are specifically in inventory 'percieved' permissions, vs rezzed and 'burned in' permissions on objects.

There is a simple test to this, create a prim in world, Rename it Prim (Open)', open permissions, and take it into your inventory. Make a second one, and this time name it 'Prim (rezzed & Permed), while it is rezzed and this time set it no copy next owner, while its still rezzed, and then take it into your inventory.

Now, while in your inventory, rename the first object Prim (Inventory Permed), and apply next owner no copy to it.

You should now have two objects, both 'visibly' no copy in your inventory, one of which was set in world, and one which you directly set in your inventory.

So... will those two objects 'behave' the same to another avatar whom you give or sell them to?

if you answered yes, you are unfortunately very likely wrong.

Give the objects to an alt... and look at them in the alt's inventory, both will say (no copy) and appear as such... that all looks good.

Now rez them from this alt....

There is a decent chance, and it can vary somewhat depending on sim and asset speediness etc, but there is a good chance that you will not have the 'same' two objects on the ground that you just had in your inventory...

The one you rezzed and permed in world will absolutely 100% be the same, but theres a good chance the one you renamed and RE PERMED in inventory, will have actually reverted to its last REZZED permissions...

It may very well be called 'Prim (Open), and it may very well now be full perms for the person to take back into their inventory, and make as many copies as they would like (same applies to transfer perms as well).

The best explanation we ever got was that the in inventory permissions are not quite the same things as the rezzed permissions, at least, not for objects. And when you rez an object, there is a decent chance it will revert to its last rezzed state, and loose any changes that have happened since that time.

I will say that since that one time we have always ALWAYS done all object permissioning in world, and even inventory centric things like skins and gestures etc in a rezzed, in world prim and then taken copies back to use for distribution. And since that time, december 04 or so, we have never had a single permed object ever 'loose' those perms again.

Yes, its slower, yes, it can be a real PITA when you have 800 parts you have to do it for. But whatever the state of the LL database/sim performance, those perms/properties when rezzed, stay. And alot of the inventory set ones, simply don't.

(for the record, i've done this at this point with close to 8000 parts, which really really sucks, but the alternative, i think we can all agree that kind of sucks alot more)

IF the misunderstanding was the cause, and the object was to apply the permissions the first time it is rezzed, shouldn't they apply the instant the customer rezzes the item in world and tried to edit it???

And what is this rezzing Torley's permission guide talks about? Is that rezzing on floor only?

When one makes multiple items into new permissions she has to do that in her inventory... so what after, shouln't the new permissions be apllied the instant I box the objects??? Do I have to box them after rezzing them on floor....aaarrgh

This is very very bad... how does one update her whole productline if wearing is not enough for applying the permissions??

to rez 129 multi-prim objects in world is not something one does in bulk.

Other people using the server 1.25.6.113484
have also experienced similar issues, with scripts too.

but never EVER give/sell/etc a prim based item to people without having first set the permissions on a REZZED copy of it

or more simply...

never perm prims inside of an inventory, ever, for any reason, ever (not yours, not an objects)

the second you do that yer pretty much sunk, sure the chances of it goin bad are remote, but they are not zero, and i doubt they ever will be.

even if its one in a thousand.. where does that leave you when you've sold yer 50,000th widget? with 50 of them open perms to people out there, and all it takes is one of them not to be 100% honest and then you won't see a dime from the 'next' 50,000 people to get them

attachement coming soon

Rez a whole pile of seperate prim parts, drag/shift/whatever multi select them all at once, and right click properties.

Then just set the desired permissions on the whole 'stack' you have selected in one go.

It may take a minute for them to all set themselves, but then ya can pick up each one in turn, and they will all be locked into the right permissions. Thats saved me countless hours heh (and is actually faster than inventory selecting if you do it well)

OBVIOUSLY rezzing the items IN WORLD

I S -N O T - E N O U G H

600 objects

now if each of these 600 objects have approximately 100 prims each... then I´d have 60 000 prims on my land

can not do all them at once in world

BUT I - CAN - set all their permissions at once in my inventory

we seriously need also changes in inventory made permanent!!

I just tried this:

I rezzed the objects I wanted to be mod copy no trans from my inventory on floor

They already had the correct permissions, but I clicked all three sets once more, to remake the permissions

then I took them back in inventory. All permissions were fine.

Then I moved them into the box in order to make a package.... checked their permissions and suddenly they were

no mod copy no trans.... which are the permissions of the script inside the hair.

Now is there a way for me to even know, in any way, which permissions apply???

If I change the permissions in the box now, will they stick?

And I never see the slam bit asterix ( * ) the http://web.archive.org/web/20070113223510/http://secondlife.com/knowledgebase/article.php?id=336 talks about.

Shouldn't it be there even after all the time in the Earth if they were never applied?? Should not them be there on this particular example product of mine I used on the pdf??? You can see on your own eyes it is not there!!!

You don't have to do them ALL at once, god knows with 9000 avatar attachment parts for well over 400 full avatars i couldn't rez them all at once to redo anything, but when i am setting them i do it in batches of maybe 10 or 20 parts at once (one full avatar).

Any permissions set on prim objects in any inventory will risk this bug. The only way to ensure you never get hit by it is to only set object permissions WHILE they are rezzed in world. nothing else will get around this problem.

Honestly what they should do is simply block access to setting permissions on prim objects while in inventory with a dialog saying that prim parts need to be rezzed in world for permissions to apply properly.

HOWEVER I set my permissions rezzed in-world, they always bounce back to the permissions the script inside has
when I put them in the box.

If editing permissions in a box would become impossible, then all I could ever sell were objects with same permissions as the scripts in them.

I do not want people to modify my scripts... but I would like the customer to be able to edit the hair to fit better

The prim object is still whatever prims it was set in world. (lets say for the sake of argument here, copy, mod, no transfer)

If you put a sound inside that you set no copy, mod, no transfer...

The object will then to someone's inventory 'look' no copy, mod, no transfer... but thats not the 'whole' story...

that is just to keep someone from copying the no copy sound by copying the copy ok head that it is in... If they take the sound out of the head, they can copy the base head to their hearts' content...

Same goes with modify and transfer, if any part inside an object is set without a permission, the set in inventory will 'reflect' that most restricted behavior across all its contained parts, to prevent duplication/transfer of no copy/nomod stuff inside of it... That more restricted permission however will NOT apply to the prims, once the inventory items inside of them have been removed... so don't use a 'no copy' script on an attachment and assume that attachment will not be copyable... it just won't be copyable unless someone removes that script... at which point someone could copy it as much as they like.

I think that may be whats confusing you

Perhaps another small client patch could be to 'hilight' derived permissions differently than set permissions, i.e. a copy ok hairdo which has a no copy script would still say no copy in inventory, but a different color than the nocopy it gets when the object itself is set that way

I am really talking about the permissions I see on the properties page.

And I want my hair to have more wide permissions than the script inside has.

In order to be able to do that, because this bug we are talking about, the permissions I have changed the item rezzzed on floor, does not
stick, when I drag the items from my inventory to the box.

So, I am forced to edit the properties page inside the box inventory and just hope the next owner will have all set correctly.

That is the another issue, the another is the issue I talked before and made the pdf about.

what you are speaking about is the default way it SHOULD be working... it just does not work like that because of the bug