Ubuntu

rm does not preserve root by default

Reported by K.Mandla on 2007-12-06
22
This bug affects 1 person
Affects Status Importance Assigned to Milestone
coreutils (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: coreutils

The rm command includes a "--preserve-root" option to prevent the accidental deletion of the root directory, but that behavior is not the default in Ubuntu 7.04 or 7.10. According to the Ubuntu man pages for rm, "--no-preserve-root" is the default.

Reversing this default would help protect new Ubuntu users, who may or may not understand the effects rm can have on the root directory. This weakness, and the repercussions it has, is best described by forum administrator jdong here:

http://ubuntuforums.org/announcement.php?f=73

Experienced users who need (for some reason) to remove an entire root directory would no doubt find a way to circumvent that particular behavior, most likely with the "--no-preserve-root" flag, or a variation on the command.

To reproduce this bug, install Ubuntu and issue the "sudo rm -rf /" command from a terminal. Of course, this should be done from a virtual environment, or from a spare installation. :)

(Edit: I corrected the link above.)

I can confirm this behavior. Other distros have taken steps to protect unknowing users from wiping their root directory, and it seems as if it should be easy enough for Ubuntu to do the same. Malicious people do exist....

Here is a proposed solution: simply add the following to /etc/bashrc and /etc/profile from now on:

alias rm=”rm –preserve-root”

K.Mandla (k.mandla) on 2007-12-06
description: updated
Dr Small (drsmall) wrote :

But that would mean that every new user would have to add that to bashrc and profle, files. No, this should be delt with so Ubuntu will protect itself, even in the hands of new users.

Luciano Montanaro (mikelima) wrote :

So, what's next? Patch dd to prevent it from wiping your partition?

There are infinite ways to wipe your root file system. There is little value in adding a safety here, while a slight variation of the theme would produce analogous damage.

@Dr Small - I'm suggesting this change would be made in the default profile and bashrc files that ship with the standard Ubuntu release.

This way:

1. novice users are protected by default
2. anyone who really wants to delete / can use --no-preserve-root attribute
3. people who prefer the default behavior can sudo and remove these lines or use .bashrc and .profile to override them

Altering the binary so that it uses –preserve-root as the default choice would work fine too. Anyone wishing to delete / could still do:

rm -rf --no-preserve-root /

Sometimes more typing is a good thing - for example when you are about to wipe your root partition.

@Luciano - note that Sun implemented this very "feature" in Solaris 10:

http://blogs.sun.com/jbeck/date/20041001#rm_rf_protection

I'm not saying we should follow Sun's example, but their choice to implement it shows that many people do think this is an issue.

Patrick Dung (patrick-dkt) wrote :

Also, this prevent typeo by root:

# rm -rf / tmp/*

The space after slash really makes a different.
Also there is no confirmation for 'rm -rf /'.

So turn on protection is much safer.

Changed in coreutils:
status: New → Confirmed
Sidarth Dasari (sirsid) wrote :

There should at the very least be a warning with a yes/no prompt and then have the user type in the root password one more time to finalize it. This at least prevents anything rash from happening. As mackial stated, more typing may be a good thing in this instance.

K.Mandla (k.mandla) on 2007-12-09
description: updated
Mark (mark-fangorn) wrote :

Just to prove to experienced users that --preserve-root by default is a benefit:
I consider myself a seasoned Linux user. Been using Linux for more than a decade. I recently toasted a filesystem with rm -rf /. What I actually typed though was something like:

f=/path/to/somedir rm -rf $f/ ; some_command $f; cp something $f/somewhere

Looks safe? Look again, I forgot a semicolon after f=/path/to/somedir. Effectively that was the same as type rm -rf /. If you want to try this out and not toast your root file system do this:

f=/home/user; echo rm -rf $f/
then this:
f=
f=/home/user echo rm -rf $f/

And see what would have ran without the echo. I'm a lot more paranoid about typing rm as root now. I always stop before pressing the enter key. If you don't think you would ever type something like this, think about any scripts you may have written where you call rm with a variable. Are you sure the variable got set? I'm posting semi-anonymously out of embarassment. *hangs-head-in-shame*

Murat Gunes (mgunes) on 2008-02-11
Changed in coreutils:
importance: Undecided → Wishlist
Adam Porter (alphapapa) wrote :

This is very important! As Mark has demonstrated, it is easy to do this by accident, even if you are experienced! Simply hitting Enter or the spacebar too soon could also do it!

"rm" should be aliased to "rm --preserve-root -i" by default! Please make this change in Hardy!

C de-Avillez (hggdh2) wrote :

This is now the default behaviour of 'rm' on Intrepid (and, it seems, on Hardy, since both package coreutils 6.10):

(I have to say that I ran this test, huh, worried, even if I was setting '-i' ;-)

hggdh@xango2:/usr/src/buildd/coreutils-6.10/coreutils-6.10 $ lsb_release -r
Release: 8.10
hggdh@xango2:/usr/src/buildd/coreutils-6.10/coreutils-6.10 $ rm -ri /
rm: cannot remove root directory `/'
hggdh@xango2:/usr/src/buildd/coreutils-6.10/coreutils-6.10 $

Also, the following notice in the info pages is relevant here:

"2.9 Treating / specially
========================

Certain commands can operate destructively on entire hierarchies. For
example, if a user with appropriate privileges mistakenly runs `rm -rf
/ tmp/junk', that may remove all files on the entire system. Since
there are so few legitimate uses for such a command, GNU `rm' normally
declines to operate on any directory that resolves to `/'. If you
really want to try to remove all the files on your system, you can use
the `--no-preserve-root' option, but the default behavior, specified by
the `--preserve-option', is safer for most purposes.

   The commands `chgrp', `chmod' and `chown' can also operate
destructively on entire hierarchies, so they too support these options.
Although, unlike `rm', they don't actually unlink files, these commands
are arguably more dangerous when operating recursively on `/', since
they often work much more quickly, and hence damage more files before
an alert user can interrupt them. Tradition and POSIX require these
commands to operate recursively on `/', so they default to
`--no-preserve-root', but using the `--preserve-root' option makes them
safer for most purposes. For convenience you can specify
`--preserve-root' in an alias or in a shell function.

   Note that the `--preserve-root' option also ensures that `chgrp' and
`chown' do not modify `/' even when dereferencing a symlink pointing to
`/'."

As such, I am closing this bug as "Fix Released". Please feel free to reopen if you do not agree.

Changed in coreutils:
status: Confirmed → Fix Released
Andrew Hohenstein (capncrunk) wrote :

Someone uninformed enough to paste "rm -fr /" into a terminal because someone on a forum told them to is also uninformed enough to paste "rm -fr --no-preserve-root /" or "cd ~/; sudo rm -fr ../../*" or "rm -fr /lib" or "rm -fr /usr" or blindly type yes/click OK on the manditory warning dialog, which most people do anyway with dire consequences. I fail to see the point.

Also, anyone not double-checking (tripple if needed) their data-destroying scripts (or one-liners) for type-os before execution, 'seasoned linux user' or not, deserves what they get when they hit 'enter.'

Changes of this nature are destructive to the philosophy of *nix, and is a step closer to the laughable click-the-dialog-box security of Windows Vista.

Andrew Hohenstein (capncrunk) wrote :

Also, this directly conflicts with the functionality of the '-f' switch, without which there ALREADY IS CONFIRMATION OF EVERY DELETION.

Endolith (endolith) wrote :

"'seasoned linux user' or not, deserves what they get when they hit 'enter.'"

No, they don't. This is contrary to the philosophy of Ubuntu. We should have even more safeguards then this. Software should be helpful and forgiving.

If a dangerous command has no reasonable purpose, it shouldn't be possible to do it by accident.

Andrew Hohenstein (capncrunk) wrote :

"no reasonable purpose,"

Not even in a chrooted environment? You seriously can't think of any reason to want this command?

"This is contrary to the philosophy of Ubuntu."

Ubuntu is better than Windows partially due to it's superior security features. Clicking a dialog box to confirm something doesn't make it less likely to happen really. We've all seen that in Windowsland.

Those of you having done End User support, how many Windows users have you talked to complaining about an error that keeps coming up, only to find they never actually read the error, just clicked it away? Or talked to a user that deleted or modified a key file, breaking the system, regardless of the thousand "ARE YOU SURE?" dialog boxes thrown at them? Which leads me to:

"We should have even more safeguards then this." (I'm assuming you meant "than" this)

One of the main reasons people ignore warning dialogs in Windows is because they come up all the time. They're seen so often that users are conditioned to have to click "OK" for everything, no matter what. It annoys them to the point that every time they see a dialog they think "YES FOR THE LAST TIME I'M SURE" without really thinking it through. Having 'even more safeguards' is going to worsen the problem in just that way.

These users are probably moving over from Windows anyway, and already have that deep-seeded hatred of warning dialog boxes, so even just this one probably isn't going to help them.

Also, are you seriously saying that people don't deserve errors when they don't proofread their scripts? Are you saying that people deserve to have their scripts run as-expected the first time every time and that the OS should have 'safeguards' in place to make sure that happens?

Andrew Hohenstein (capncrunk) wrote :

The point is that the intended effect of this change won't happen, as the method is already proven ineffective, and there are literally thousands of other possible command sequences that can hose a system in the same way, and having confirmation for them all just makes easy, uncomplicated, and efficient operation of the OS impossible (also something Ubuntu strives for).

Andrew Hohenstein (capncrunk) wrote :

"These users are probably moving over from Windows anyway, and already have that deep-seeded hatred of warning dialog boxes, so even just this one probably isn't going to help them."

Not only that, it could potentially deter users, sending them back to use Windows, thinking "Hey, this is just as annoying as Windows, only I can't run Outlook!"

I think we all want to keep the "philosophy of *nix" alive and well;
without it, we probably wouldn't even have Ubuntu today. And we all
want to make Ubuntu better and more useful; we don't want it to
stagnate and become irrelevant. And we'd hope to gain more users and
build community along the way.

But what exactly is the philosophy of Unix? Is the real philosophy of
Unix to take no precautions against simple mistakes that anyone, even
the most experienced user, can make? Mistakes that can have
catastrophic consequences?

Unix is a great foundation, but it isn't rooted in goodness towards
others. But Ubuntu is intended to be. Personally, I'm thankful that
I don't always get what I deserve, because I'd be in bad shape if I
did. Just as we should be forgiving to each other, so should the
systems we design be forgiving to their users. That doesn't mean
having endless popup boxes; in a case like this, it's a simple fix for
a huge payoff. And what's the downside? Non-compliance with a man
page or an old tradition? We can change both of those. We have the
technology. :)

Andrew Hohenstein (capncrunk) wrote :

I'm not trying to preserve the 'philosophy of *nix,' I'm trying to
preserve the functionality of the rm -fr command. I mention the
'philosophy' only to point out it's wisdom.

My point is that setting a precedent of implementing security features
that are already proven ineffective is destructive to the whole reason
Ubuntu exists as an alternative to Windows. Adapting the same failed
methods just blurs the distinction, compromises security, and deters
users.

There are already other blocks (proven more effective) in place for
this command (sudo (already requiring a password), the -f switch, etc)
that more inexperienced users shouldn't be using, or should be
uncomfortable enough with them not to use them all the time anyway,
and anyone experienced enough to use them should know when not use
them, as well as proofread their scripts every time and develop habits
that don't invite the opportunity for a type-o to delete a partition.

That being said, over the years the number of times I've accidentally
run 'rm -fr /' successfully is zero, and I haven't found anyone I know
that has either. I would imagine the relative number of experienced
users affected by accidental invocation of a 'sudo rm -fr /' command
is pretty low.

Even if I were to do it myself, it wouldn't be all that detrimental to
me as I do daily backup which, by the way, is also a good habit that
even inexperienced users develop pretty quick.

Andrew Hohenstein (capncrunk) wrote :

I'm not trying to preserve the 'philosophy of *nix,' I'm trying to preserve the functionality of the rm -fr command. I mention the 'philosophy' only to point out it's wisdom.

My point is that setting a precedent of implementing security features that are already proven ineffective is destructive to the whole reason Ubuntu exists as an alternative to Windows. Adapting the same failed methods just blurs the distinction, compromises security, and deters users.

There are already other blocks (proven more effective) in place for this command (sudo (already requiring a password), the -f switch, etc) that more inexperienced users shouldn't be using, or should be uncomfortable enough with them not to use them all the time anyway, and anyone experienced enough to use them should know when not use them, as well as proofread their scripts every time and develop habits that don't invite the opportunity for a type-o to delete a partition.

That being said, over the years the number of times I've accidentally run 'rm -fr /' successfully is zero, and I haven't found anyone I know that has either. I would imagine the relative number of experienced users affected by accidental invocation of a 'sudo rm -fr /' command is pretty low.

Even if I were to do it myself, it wouldn't be all that detrimental to me as I do daily backup which, by the way, is also a good habit that even inexperienced users develop pretty quick.

Adam Porter (alphapapa) wrote :

On Mon, Apr 13, 2009 at 23:25, Andrew Hohenstein <email address hidden> wrote:
> I'm not trying to preserve the 'philosophy of *nix,' I'm trying to
> preserve the functionality of the rm -fr command. I mention the
> 'philosophy' only to point out it's wisdom.

How do you define that philosophy, then? I don't understand what you mean.

> My point is that setting a precedent of implementing security features
> that are already proven ineffective is destructive to the whole reason
> Ubuntu exists as an alternative to Windows. Adapting the same failed
> methods just blurs the distinction, compromises security, and deters
> users.

It's hard for me to see how implementing this fix/feature would deter
anyone from using Ubuntu. :) To me it's not a security feature at
all; it's more akin to the safeguards in place to prevent accidental
launch of nuclear weapons. How would it be destructive to Ubuntu's
reason for existence? I don't understand what you mean.

> There are already other blocks (proven more effective) in place for
> this command (sudo (already requiring a password), the -f switch, etc)
> that more inexperienced users shouldn't be using, or should be
> uncomfortable enough with them not to use them all the time anyway,
> and anyone experienced enough to use them should know when not use
> them, as well as proofread their scripts every time and develop habits
> that don't invite the opportunity for a type-o to delete a partition.

There are many things that people, even good people, should do, but
don't. Is "they deserve what they get" the kind of attitude Ubuntu
wants to project? Is that even how we should treat other people? I
don't understand what your goal is with Ubuntu. What you're calling
for sounds more like it belongs in a distro like...Slackware? Gentoo?
 Please explain what you're trying to achieve here. :)

> That being said, over the years the number of times I've accidentally
> run 'rm -fr /' successfully is zero, and I haven't found anyone I know
> that has either. I would imagine the relative number of experienced
> users affected by accidental invocation of a 'sudo rm -fr /' command
> is pretty low.

I've read some horror stories; they aren't hard to find online. I am
a very careful driver, with a clean record, but just the other day a
fellow and I backed into each other in the parking lot. No one is
perfect; mistakes happen to the best of us. Thankfully the damage was
minor, and both of us were kind and understanding towards the other.
To me, that is the kind of attitude Ubuntu is about.

> Even if I were to do it myself, it wouldn't be all that detrimental to
> me as I do daily backup which, by the way, is also a good habit that
> even inexperienced users develop pretty quick.

Who are these inexperienced-yet-diligent users of which you speak? :)

Endolith (endolith) wrote :

> These users are probably moving over from Windows anyway, and already have that deep-seeded hatred of warning dialog boxes, so even just this one probably isn't going to help them.

So instead of asking the user if they really want to delete their entire filesystem... we should just assume that's what they really meant and do it without asking? I'm not sure how you think this an improvement.

> The point is that the intended effect of this change won't happen, as the method is already proven ineffective

Shouldn't synonyms like "sudo rm -fr ../../*" in the home directory be prevented, too? It should be based on the actual effect the command has, not a particular string. If not, I would think that's a bug.

> and there are literally thousands of other possible command sequences that can hose a system in the same way, and having confirmation for them all just makes easy

There's protecting the user against pasting malicious commands, and there's protecting the user from the results of an unfortunate typo. Even experienced users make stupid mistakes like this (http://www.justpasha.org/folk/rm.html), which is why "preserve root" is the default behavior in GNU rm:

http://www.gnu.org/software/coreutils/manual/html_node/Treating-_002f-specially.html

If "the *nix philosophy" means "the user deserves to lose their life's work over a simple mistake", then I don't see any value in keeping that particular "philosophy" alive.

Maybe you'd be happier with something like Arch Linux?

Zack (zack-gilburd) wrote :

This is ridiculous. What's next, hiding the terminal until a user clicks Start => Run and types in 'cmd'?

Andrew Hohenstein (capncrunk) wrote :
Download full text (6.1 KiB)

I found another bug in Ubuntu... It actually allows you to install the system to a hard disk! This means that not only does it leave the system open to 'sudo rm -fr /' commands being run accidentally, but anyone passing by with an active electro-magnet could corrupt the entire system. Other distros (Knoppix, etc) circumvent this by being a live-CD-only distribution. Ubuntu already has live-CD functionality, so all we need to do is just cut out all the installable stuff, and it's good to go! Right? We could also include a requirement of lead shielding in the chassis.

..end sarcastic portion of update..

> To me it's not a security feature at all; it's more akin to the safeguards
> in place to prevent accidental launch of nuclear weapons. How would it
> be destructive to Ubuntu's reason for existence?

I obviously don't really know what all is involved in the physical act of firing a nuke, but if the movies are to be believed, it takes the right person giving the proper authorization (sudo) and giving the command to fire (rm -fr).. Usually it takes more than one person doing it at the same time, but short of forcing two different admin users to confirm file deletions so that it lives up to this standard, at some point the engineers make the determination that any more safeguards preventing execution would be too much (even unsafe), because after all the weapons (commands) are there to be used, not look pretty.

This single feature is not destructive by itself, the precedent it sets is. Users will expect the system to save them from themselves doing anything potentially destructive, citing this 'bug' as 'proof' just like everyone here did ("Sun is doing it why shouldn't we?" is, I'm sorry, a glaring logical fallacy).

> There are many things that people, even good people, should do, but don't.
> Is "they deserve what they get" the kind of attitude Ubuntu wants to project?

So upon installation, should the disk partitioner not actually allow a user to format a partition that has a certain amount of files with 'last modified' dates of today's date, for fear that the user is actually choosing the wrong partition to format? I bet a lot more people have made that mistake than have accidentally run 'sudo rm -fr /'... And the answer is still no, the partitioner shouldn't just refuse to format the partition it was told to format during install because the user didn't run it with the --actually_format_stuff flag, or something.

Someone always deserves a broken foot when they ask themselves, "Hmm, I wonder what will happen if I drop this bowling ball on my foot?" and then does it. Even if they meant to drop it an inch to the left of their foot, and not right on it. It's not the bowling ball manufacturer's fault for making a bowling ball that hurts your foot when dropped upon it. Nail guns don't come with built-in sensors that detect living tissue in front of it and refuse to fire if there is. You're just not supposed to aim it at yourself, the safety button (sudo, -f, etc) is considered to be enough.

The Ubuntu home page says "Ubuntu is designed with security in mind" and that it's made to be easy to install and get up and running on most computers...

Read more...

Adam Porter (alphapapa) wrote :
Download full text (8.2 KiB)

On Tue, Apr 14, 2009 at 22:07, Andrew Hohenstein <email address hidden> wrote:
> I found another bug in Ubuntu... It actually allows you to install the
> system to a hard disk! This means that not only does it leave the system
> open to 'sudo rm -fr /' commands being run accidentally, but anyone
> passing by with an active electro-magnet could corrupt the entire
> system. Other distros (Knoppix, etc) circumvent this by being a live-CD-
> only distribution. Ubuntu already has live-CD functionality, so all we
> need to do is just cut out all the installable stuff, and it's good to
> go! Right? We could also include a requirement of lead shielding in the
> chassis.
>
> ..end sarcastic portion of update..

I can see you're quite passionate about this idea. I confess that I
don't understand why it's such a big deal to you. It's very simple to
use --no-preserve-root in your aliases. Anyway, it might make for
better discussion if we avoided sarcasm. Let's keep our common goals
in mind: we all want to improve Ubuntu.

> I obviously don't really know what all is involved in the physical act
> of firing a nuke, but if the movies are to be believed, it takes the
> right person giving the proper authorization (sudo) and giving the
> command to fire (rm -fr).. Usually it takes more than one person doing
> it at the same time, but short of forcing two different admin users to
> confirm file deletions so that it lives up to this standard, at some
> point the engineers make the determination that any more safeguards
> preventing execution would be too much (even unsafe), because after all
> the weapons (commands) are there to be used, not look pretty.

I didn't want to mention the movies, because I'm sure they leave a lot
to be desired in the Reality Department. But even in the movies, it
usually takes multiple physical keys to unlock the Big Red Button. :)

> This single feature is not destructive by itself, the precedent it sets
> is. Users will expect the system to save them from themselves doing
> anything potentially destructive, citing this 'bug' as 'proof' just like
> everyone here did ("Sun is doing it why shouldn't we?" is, I'm sorry, a
> glaring logical fallacy).

Respectfully, I think your argument in this paragraph is a logical
fallacy, along the lines of a Slippery Slope argument. Just because
the rm command by default prevents the deletion of / doesn't mean that
users "will expect the system to save them from themselves doing
anything potentially destructive." Just because a car has seatbelts,
airbags, and anti-lock brakes doesn't mean that people believe they
can safely aim their car towards the edge of a cliff. We're talking
about one minor option that prevents accidents, an option that can be
easily disabled by anyone who is bothered by it.

> So upon installation, should the disk partitioner not actually allow a
> user to format a partition that has a certain amount of files with 'last
> modified' dates of today's date, for fear that the user is actually
> choosing the wrong partition to format? I bet a lot more people have
> made that mistake than have accidentally run 'sudo rm -fr /'... And the
> answer is still no, the partitione...

Read more...

Andrew Hohenstein (capncrunk) wrote :

> Respectfully, I think your argument in this paragraph is a logical fallacy,
> along the lines of a Slippery Slope argument.

There is no slippery slope, no string of events, just one event
causing another, a precedent set.

> Just because the rm command by default prevents the deletion of
> / doesn't mean that users "will expect the system to save them from
> themselves doing anything potentially destructive."

Well, someone sure did the same thing here, and nobody objected...
Luke Maciak (tuxmentat) wrote on 2007-12-06 "...@Luciano - note that
Sun implemented this very "feature" in Solaris 10...I'm not saying we
should follow Sun's example, but their choice to implement it shows
that many people do think this is an issue." You don't think if I went
through other bug reports I'd find many people using the same logic?
How many times do you think these arguments get opposed?

> Just because a car has seatbelts, airbags, and anti-lock brakes doesn't mean
> that people believe they can safely aim their car towards the edge of a cliff.

Want to bet on that?

http://www.motorauthority.com/sat-nav-strikes-again-uk-driver-nearly-goes-off-cliff-following-gps-directions.html

Besides crashing a car is never the intended use of a car, except when
they're crash testing or filming a movie or something, but that's
intentionally causing a problem and not using them for their intended
use (transportation). The rm command is supposed to delete the files
you tell it to.

> We're not talking about the partitioner; only the rm command. Since
> you brought up logical fallacies, is this an example of a Red Herring?

Nope, it's applying the logic of the pro argument here to another
situation in an attempt to make clear it's ridiculousness. A red
herring is an attempt to distract from the actual discussion at hand.
An example of a red herring would be something like:

> I can see you're quite passionate about this idea. I confess that I
> don't understand why it's such a big deal to you.

Also..

> Respectfully, you seem to be taking the argument to absurd extremes.
> No one's calling for Ubuntu to be like that.

This 'bug' *IS* taking it to this extreme. The whole premise is that
'experienced' users allegedly destroy entire systems with no chance of
recovery by mis-typing an rm command, which is a product of either
lack of backup, lack of proofreading, or lack of actual experience.
Ignorant users pasting it into a terminal window would paste a string
with '--no-preserve-root' in it anyway, because they're not likely to
know what it means. Beyond that, the only argument for it is that
doing anything else makes Ubuntu a crabby hard-ass old man that nobody
wants to hang out with because he deletes your files if you look at
him funny, or that "SunOS is doing it so why shouldn't we?".

> I don't understand your point

Then read it again, it's pretty clear. Try not just focusing on the
last sentence of the paragraph. It might help.

C de-Avillez (hggdh2) wrote :

@all: may I suggest you move this discussion to the ubuntu, or the devel-discuss mailing lists?

It makes not much of a sense to keep discussing on a closed bug; if you feel that strong that 'rm' should not remove directories (and please note that -- on current coreutils -- you *must* use --no-preserve-root if you want to completely clean up your system), then this is really not the ideal discussion point.

Thank you.

Could people have a look at standards instead of trolling?

SUSv4 adds the following exception:

« if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands. »

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers