On 2/23/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:
Hi,
ext Gustavo Sverzut Barbieri wrote:
>> > yes, but the most harmful action is to add "/" to be scanned, but
>> > that's in blacklist so it's avoided.
>>
>> If it is monitoring file changes in the device, you should also
>> ignore at least /dev & /sys*, otherwise your process wakes up
>> unnecessarily (which drains battery).
>
> Sure, we ignore:
>
> static const gchar *blacklist[] = {
> "/bin",
> "/boot",
> "/dev",
> "/etc",
> "/lib",
> "/proc",
> "/root",
> "/sbin",
> "/sys",
> "/usr/bin",
> "/usr/sbin",
> "/usr/etc",
> "/usr/lib",
> NULL
> };
Any particular reason why you're not ignoring "/var" (where can
be log files etc) and "/tmp" (where are locks, sockets and app state
data etc) which get often updated?
I've replyied in another mail, but here it goes: some users may have
maemo on MMC/SD and media under /var/media or /var/lib... but ok, it's
a rare case. I'll make this blacklist came from GConf, pre-defined
with /tmp, /var and others except /home and /media
Btw. As a general security rule (this is not about security but..),
it's better to allow things that are known to be safe and ignore
rest than try to deny things (because that way you will always miss
some new exploits).
It's kinda hard to implement whiltelist for end-user (or not security
aware user) applications. Users tend to want things their ways, you
cannot force them and tell our way is right, just check
https://garage.maemo.org/tracker/?func=detail&atid=529&aid=499&group_id=125
Anyway, it's a blacklist to let user choose his whitelist... We just
scan what user choose.
If the server is interested only about media files, it's better to
allow only stuff under /home and /media. And if you're checking
stuff under /media, you SHOULD be promptly reacting to unmount
messages[1] for the media cards. I've gotten some (unconfirmed)
doubts that if something is blocking memory card unmounting and it
needs to be forced (e.g. at shutdown), that sometimes might corrupt
the FAT[2] filesystem on users' memory cards.
[1] Gconf key updates for:
- /system/osso/af/mmc-cover-open
- /system/osso/af/usb-cable-attached
- /system/osso/af/internal-mmc-cover-open
Actually we listen for GnomeVFS DBus events: mount, unmount and pre-unmount.
pre-unmount is used to let us copy canola.db to it before it's
unmounted. It's used to let PC applications like syncropated to
configure existing DB (it read from existing tables and then store SQL
queries on backlog table, that will be executed by canola, not used so
far).
So, canola-conf can cause problems while copying canola.db, but just
if user force removal, since filesystem isn't unmounted if there are
open files.
[1] Microsoft in 80's didn't really "design" FAT to be robust...
And as can be learned from the issues with metalayer-crawler,
inserting a memory card with corrupted FAT can create some
interesting problems unless developer takes extra pains to
handle error cases like:
- infinitely recursing directories and this doesn't mean just ignoring
(directory) symlinks, but actual (corrupted MMC FAT) filesystem
directories being recursive
- errors on allocations and with directory/file reads *and* reacting
correctly to them i.e. not retrying (at least more than couple of
times), but canceling/unwinding (suitable part of) the operation
Yeah, we've experienced some, but most were due using SWAP on MMC.
Anyway, N800 should reduce these problems and copy of canola.db to mmc
may vanish if required.
Thanks for feedback!
--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
Phone: +1 (347) 624 6296; [EMAIL PROTECTED]
GPG: 0xB640E1A2 @ wwwkeys.pgp.net
_______________________________________________
maemo-developers mailing list
[email protected]
https://maemo.org/mailman/listinfo/maemo-developers
