On Tue, Nov 11, 2008 at 03:50:05PM +0000, Magnus Lewis-Smith wrote: > Chris (and everyone else)
Hi Magnus, Thanks very much for your detailed report on permissions in Opensuse! I finally got a chance to study this more closely, and hack around on an OpenSUSE 11 box, trying to make this stuff all just work. It took much longer than I thought it should take, and I still don't have it worked out. I figure it's time to do a brain dump on the mailing list and let people help out. I suspect that this issue may be related to the recent ArchLinux permissions thread as well: http://sourceforge.net/mailarchive/forum.php?thread_name=20081106162545.GB4511%40arcangeli.org&forum_name=barry-devel > Some time ago you asked for some help investigating the usb device > permissions on OpenSuse. I didn't see if you had any responses to that, > so I don't know if the following information will be any use... During my testing, it is obvious that Barry on Opensuse needs work. :-) The more help, the better. > It seems that udev has a rule in > /etc/udev/rules.d/50-udev-default-rules > SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", > NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644" > > which sets the usb device to being read-only, and overrides the settings > provided in /etc/udev/rules.d/10-blackberry.rules > > The workaround I have implemented is to move the blackberry rules file to > later in the sequence, This is valuable to know. In my tests, when I changed the sequence of 10-blackberry.rules, it took much longer for bcharge to run. And one time, I think it didn't run at all. Did you run into any such problems? > In fact, in my own setup I've found the serial number of my blackberry: > > # lsusb > ... > Bus 005 Device 023: ID 0fca:0004 Research In Motion, Ltd. > ... > # udevinfo -a -n /dev/bus/usb/005/023 | grep 'ATTR{serial}' > > and set up the rule as > ... ATTR{serial}=="abcde", OWNER="myusername", MODE="0600" ... I assume this is the same serial number that shows up in 'lsusb -v' output. side question to Martin Owens: I notice in your fdi and hal-blackberry script, you set 'sync.serial' in hal to the pin number. Is this a possible mistake? Should we be naming that 'sync.pin' instead, in case the serial number ever becomes useful? > I'd prefer to have ConsoleKit configured so that this just works, but I > haven't the foggiest about how to do that. Opensuse does use ConsoleKit, > but doesn't seem to pay attention to the file > /etc/security/console.perms.d/10-blackberry.perms I'd like this too. :-) It appears that modern linux desktops are moving toward hal, ConsoleKit, and PolicyKit more and more, and things like udev rules to change the device permissions are becoming more out of date in the world of Fast User Switching. As I understand it, there is a maze of XML fdi files under /usr/share that govern how device permissions are set. I haven't completely figured out how the above 3 systems work together, but you do need: - a kernel with POSIX access control lists enabled - a filesystem with acl enabled (in the case of ext2/ext3, you may need to specifically enable this in /etc/fstab, with the 'acl' and 'user_xattr' options) - hal sets the acl's for the devices on the fly, according to policy in the XML files under /usr/share - ConsoleKit keeps track of what user is at the console, etc - I have no idea how PolicyKit fits in So ideally, I'm assuming that Barry should install an fdi file somewhere that makes sure that Blackberry devices are set rw for the active console user. I don't know if this is Barry's packaging job, or hal's job, to update their hal-info data for Blackberries. What is unclear to me is which fdi files are part of the system, and which files are part of the administrator's policy, and which should be changed to reflect how the admin wants to setup his system. It would seem that editable files should be located in /etc, but there are precious few such files. As for your /etc/security/console.perms.d/10-blackberry.perms being ignored, I believe that file is for PAM, when PAM was The Way to do permissions, which is also now out of fashion. If your distro relies completely on hal and ConsoleKit, the PAM config files are probably useless. Indeed, those directories are probably empty on your system in that case. I even read in certain mailing lists that distros' auto-build systems were to be updated to catch any binary packages writing config files to these directories, since that's the Wrong Thing, apparently. :-) If anyone has information to add to this thread, please do. Thanks, - Chris ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel