(In reply to comment #0)
> 1. WHen N900 is switched of and I connect it with USP to PC I can see all
> files in device and memory card ( copy, transfer, delete etc!!!

This is as intended.  Note that you omitted one crucial step above:

1. Connect device to PC with USB cable.
2. Select "Mass storage mode".
3. Access files.

> 2. This could lead to sesious problems when N900 ends up to wrong hands!!!

If you are concerned about this you can set device autolock and change the
default lock code (Settings -> Device lock).  When the device is locked the
"wrong hands" cannot select mass storage mode without unlocking it (of course
they are perfectly capable of physically removing your memory card and running
away with it but that's another story).

> EXPECTED OUTCOME:Protected with PWD or similar

This functionality is already available as described above.

Comment 2 Jussi Maaniitty 2009-12-09 12:36:00 UTC

The problem is that the description happens in all cases, also when there is
lock code assigned for the device. I've reproduced this with 49-5.

Comment 3 Jussi Maaniitty 2009-12-09 12:36:45 UTC

confirming bug

(In reply to comment #2)
> The problem is that the description happens in all cases, also when there is
> lock code assigned for the device. I've reproduced this with 49-5.

With the device locked?  FWIW it works as intended on 42-11 here:

1. Make sure USB is unplugged.
2. Set device autolock and lock code.
3. Wait for autolock, or press power button and select "Secure device".
4. Plug USB data cable (other end connected to PC).

Expected & actual outcome: device goes into charging-only mode (modulo bug
6004), no mass storage devices visible on PC side.  After unlocking the device,
the USB mode selection dialog is shown and the user can then select mass
storage mode if desired.

The bug report was about connecting a device that has been turned *off*, it
goes straight to charging+mass storage mode without asking the user when USB is
plugged in.

(In reply to comment #5)
> The bug report was about connecting a device that has been turned *off*, it
> goes straight to charging+mass storage mode without asking the user when USB is
> plugged in.

Exactly and I see that as problem msot of people are not aware of this and they
thisnk that using pin request will be enough.

(In reply to comment #6)
> Exactly and I see that as problem msot of people are not aware of this and
> they thisnk that using pin request will be enough.

You are right of course, sorry for missing the "off" bit.  And of course I
proved your point already ;-)

So the issue is that the g_file_storage module is loaded when the device boots
to the charging runlevel.  I see two places where this can happen,
/etc/event.d/bme and/or /etc/init.d/ke-recv.  Moving to system software, not
sure if the right component is mmc-and-usb or dsme though.

Comment 8 Tim Samoff 2009-12-12 04:00:57 UTC

Just a note: this also happens (maybe 5/10) when the battery is not even in the
device.

(In reply to comment #8)
> Just a note: this also happens (maybe 5/10) when the battery is not even in the
> device.

You made me shutdown to test this ;-)  Mine doesn't even boot to the charging
runlevel when the battery is removed (which is consistent with all previous
devices), I only get a brief orange LED blink and nothing USB-related logged on
the host side.

Comment 10 Tim Samoff 2009-12-13 22:19:30 UTC

(In reply to comment #9)
> I only get a brief orange LED blink and nothing USB-related logged on
> the host side.
> 

Keep trying. I'm using a Mac if it makes any difference.

I believe this is an expected behavior.

When the device is off, it'll act as an external USB harddrive.

Harddrives do not need a password to access the files when you plugged them in
(for most of them unless you have them password protected)

> 2. This could lead to sesious problems when N900 ends up to wrong hands!!!

Same with when you lose an USB thumbdrive.

This is not a bug, more like an enhancement to me, and I don't want to be
entering a password of any sort whenever I plug the device in to access my
files. There should be an option to turn this off if it is implemented.

(In reply to comment #11)
> This is not a bug, more like an enhancement to me, and I don't want to be
> entering a password of any sort whenever I plug the device in to access my
> files.

This is orthogonal (setting a lock code is always up to the user).  The issue
here is that when the device is switched off, plugging USB should only enable
charging and not mass storage mode until the user explicitly requests that. 
Similarly, it shouldn't enable access to the modem either (and it doesn't).

> This is orthogonal (setting a lock code is always up to the user).  The issue
> here is that when the device is switched off, plugging USB should only enable
> charging and not mass storage mode until the user explicitly requests that. 
> Similarly, it shouldn't enable access to the modem either (and it doesn't).
> 

I still prefer the way it is (acting as an external hard-drive) as it should
be.
If the device is off, how can you explicitly request to gain access to mass
storage mode? Turn on the device?

(In reply to comment #13)
> If the device is off, how can you explicitly request to gain access to mass
> storage mode? Turn on the device?

Well, yes.  If the user turned it off it shouldn't be doing stuff behind the
user's back.

Comment 15 Tim Samoff 2009-12-14 14:35:08 UTC

Likewise, flashing the device is impossible if the drive is mounted. Last time
I flashed, I had to plu/unplug my device (with the battery out) several times
before it didn't mount.

Comment 16 Andre Klapper 2009-12-15 15:50:45 UTC

Imported.

Comment 17 Andre Klapper 2010-01-28 01:53:21 UTC

"This had to be done as a requirement in order to pass USB certification.  
The USB spec really requires this."

Hence this cannot be changed.

Comment 18 Kimmo Hämäläinen 2010-01-28 09:37:02 UTC

(In reply to comment #17)
> "This had to be done as a requirement in order to pass USB certification.  
> The USB spec really requires this."
> 
> Hence this cannot be changed.

I don't think so. We are required to have g_file_storage inserted (to get power
from Windows PC), but actually exposing the partitions to the PC should not be
necessary. What is the internal bug number?

Comment 19 Andre Klapper 2010-01-28 12:11:58 UTC

Kimmo: See the Alias field here.

Comment 20 Kimmo Hämäläinen 2010-02-05 14:14:19 UTC

FYI: this is being worked on now. Let's see if USB certifications can pass with
the changes...

Disagree to fix this bug here.

I just ran into a situation where I forgotten my lock code. The only way is to
flash the device and without USB mass storage enabled there are no way I can
copy the backups. (I plan to flash eMMC too)

Correct me if I'm wrong.

(In reply to comment #21)
> I just ran into a situation where I forgotten my lock code. The only way is to
> flash the device and without USB mass storage enabled there are no way I can
> copy the backups. (I plan to flash eMMC too)

You don't *have* to flash the eMMC at the same time, which allows you to
recover user files from the device at your leisure.

The case discussed here is an oversight, not an intentional feature.  For
disaster recovery options see the discussions in bug 2984 & bug 6720.

I want to stress an important point made in bug 8146 and why I think this bug
should be a WONTFIX

"As with every computer: Don't let people you don't trust use it."

If we can't keep the physical device safe, the data with it, no matter how
secure, won't be safe neither.

Therefore I believe it's a waste of resources to fix this bug.

(In reply to comment #23)
> "As with every computer: Don't let people you don't trust use it."

That's part of the story, but there are also other risks with the current
behaviour when trying to charge the device on a "foreign" PC, including:
- Collecting some viruses (or vice versa, infecting an innocent PC with malware
obtained from a previously connected infected one).
- Not noticing that it has mounted the FAT filesystems, disconnecting the cable
and corrupting the filesystems.
- Having your personal data indexed on the PC.

Note that no untrusted person used the device in the above scenaria.  All these
stem from the fact that the same cable has multiple purposes and that in all
other circumstances the user is asked first before enabling mass storage. 
Doing this silently and without permission violates the principle of least
surprise and is just asking for trouble IMHO.

Comment 25 Andre Klapper 2010-02-22 19:12:19 UTC

This has been fixed in the internal build version
10.2010.06-7
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Comment 26 Andre Klapper 2010-03-15 20:57:14 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).