[Oliver Grawert] > that might be because you attach it directly to the computer device > in the tree,
Thanks for the tip. > create an ltsp devicetree first that acts as the parent for your > disk, that should give you more opportunities to fiddle with > permissions through dbus service files (there might also be a way > through consolekit/policykit without the above though). That would be nice, yes. As far as I know, hal-device add issues a NewDevice event to HAL, and get a PermissionDenied in return. According to <URL: http://people.freedesktop.org/~dkukawka/hal-spec-git/hal-spec.html >, uid=0 is required: NewDevice Objref PermissionDenied Creates a new device object in the temporary device list (TDL) and return the UDI. Caller must be uid 0. The hal code in question look like this: if (!local_interface && !access_check_message_caller_is_root_or_hal (ci_tra cker, message)) { raise_permission_denied (connection, message, "NewDevice: not privi leged"); return DBUS_HANDLER_RESULT_HANDLED; } And if I understand the access_check_message_caller_is_root_or_hal() implementation, the caller uid need to be 0 or the uid of the running hald process. :( BTW: if this approach do not work out, Sune made a new version of vaduz available using GIT from <URL: http://git.debian.org/?p=users/pusling-guest/vaduz.git;a=summary > (use 'git clone http://git.debian.org/git/users/pusling-guest/vaduz.git'). It need more work to integrate it into the desktop. Happy hacking, -- Petter Reinholtdsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
