From owner-freebsd-bluetooth@FreeBSD.ORG Mon Apr 13 23:40:14 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 583EE1065672 for ; Mon, 13 Apr 2009 23:40:14 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9258FC1D for ; Mon, 13 Apr 2009 23:40:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so151571gxk.19 for ; Mon, 13 Apr 2009 16:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Gx3BLNc/jGKo24jO8pBSBBNsoxtilm/f8sS033vT1oU=; b=xariknjCXiymQ0gsHHopQTak1Wza6o3glL2edOyJUzzoF0sJK+N+Vsb4riZzDILnEl hEEKEF8gEHdV7pn7nLo/Ej90db+YtNQTKCj84eRG6GZhx6078DLI4ppn0R8tn3P13T/B 2HugsC//3J/GPDlQwIDZ/UydtMge1kyYAMWsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uramEd8Ec+XtLAZH/5WckKuGd4wjSfCNQAUw5rgkFeHN7H5VuaHm0xQ+6fZbIYo2lM QqTmdViFWVzzdCtH+qx3D7mvOxV/gVpv9d0wD0YZuZkfxMC58RZ9vNMvWqbX+cFyBvzv 6bzZevMEIcLOsMlgOmSJuyiYBhKLeShe7msCA= MIME-Version: 1.0 Received: by 10.90.88.16 with SMTP id l16mr8945979agb.112.1239666013350; Mon, 13 Apr 2009 16:40:13 -0700 (PDT) Date: Mon, 13 Apr 2009 16:40:13 -0700 Message-ID: From: Maksim Yevmenkin To: "freebsd-bluetooth@freebsd.org" Content-Type: multipart/mixed; boundary=0016361648b35dad720467783cb8 Subject: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 23:40:14 -0000 --0016361648b35dad720467783cb8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit dear freebsd-bluetooth@ users, please find attached patch to obexapp port that add new feature of virtualizing root folder for each client device. this work was inspired by and based work done by 'mi' < mi -plus- thun -at- aldan -dot- algebra -dot- com> background various bluetooth obex profiles do not have notion of user credentials. that could be very inconvenient when multiple client devices want to store data on the same obex sever. the example that was given to me by 'mi' is when two people (say, wife and husband) want to back up their complete phone books onto the same server. the problem is that most devices use some well known name, such as phonebook.vcf and there is no obvious way to override it. how does it work obexapp now has new options '-R' that would turn new feature on. first, default root folder is set as it was before (see man page '-r' option). when client is connected, client's bd_addr is resolved to a human readable name via bt_gethostbyaddr(3) call. if bd_addr is resolved then obexapp will check for the subdirectory, under current root, with the resolved name. if name was not resolved or resolution has failed, then obexapp will look for a subdirectory that matches client's bd_addr, i.e. '01:02:03:04:05:06'. if that fails, then obexapp will look for "default" subdirectory. if later fails as well, connection is terminated. if virtual root is found, obexapp will chroot(2) into it. possible setup - create 'obex' user and 'obex' group - create '/var/spool/obex' (or whatever you want for default root) owned by 'obex' user/group - user 'foo' creates ~/private directory under his home directory with 0700 permissions - admin setups 'obex' directory under foo's ~/private/ directory with 0770 permissions, this directory is owned by 'obex' user. group is set to foo's group - admin setups symlink in /var/spool/obex/ called 'foo_cell' that points to ~foo/private/obex - admin adds entry in the /etc/bluetooth/hosts file to assign 'foo_cell' foo's cell phone bd_addr - admin run obexapp server as 'obexapp -s -r /var/spool/obex -R -u obex -C 1' every time foo's uses cell phone to send data to the obex server, the data will end up in foo's ~/private/obex directory. please give it a try and let me know it works. thanks, max --0016361648b35dad720467783cb8 Content-Type: text/plain; charset=US-ASCII; name="obexapp-uid3.diff.txt" Content-Disposition: attachment; filename="obexapp-uid3.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fthsl3j00 SW5kZXg6IG1haW4uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvdXNyL2xvY2FsL2N2cy9wb3J0cy9v YmV4YXBwL21haW4uYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMwpkaWZmIC11IC1yMS4xMyBt YWluLmMKLS0tIG1haW4uYwkyMyBBcHIgMjAwNyAxODoyOToxOCAtMDAwMAkxLjEzCisrKyBtYWlu LmMJMTMgQXByIDIwMDkgMjE6MjU6MDggLTAwMDAKQEAgLTY1LDcgKzY1LDcgQEAKIHsKIAlzdHJ1 Y3Qgc2lnYWN0aW9uCXNhOwogCWNoYXIJCQkqZXAgPSBOVUxMLCAqcHJpX25hbWUgPSBOVUxMOwot CWludAkJCW4sIHNlcnZpY2UsIG5vbmludGVyYWN0aXZlOworCWludAkJCW4sIHNlcnZpY2UsIG5v bmludGVyYWN0aXZlLCBkZXRhY2g7CiAJY29udGV4dF90CQljb250ZXh0OwogCW9iZXhfY3RyYW5z X3QJCWN1c3RmdW5jOwogCkBAIC04Myw3ICs4Myw3IEBACiAJLyogUHJlcGFyZSBjb250ZXh0ICov CiAJbWVtc2V0KCZjb250ZXh0LCAwLCBzaXplb2YoY29udGV4dCkpOwogCWNvbnRleHQudGZkID0g Y29udGV4dC5zZmQgPSAtMTsKLQljb250ZXh0LmRldGFjaCA9IDE7CisJZGV0YWNoID0gMTsKIAog CWNvbnRleHQubHNfc2l6ZSA9IE9CRVhBUFBfQlVGRkVSX1NJWkU7CiAJaWYgKChjb250ZXh0Lmxz ID0gKGNoYXIgKikgbWFsbG9jKGNvbnRleHQubHNfc2l6ZSkpID09IE5VTEwpCkBAIC0xMTksNyAr MTE5LDcgQEAKIAogCS8qIFByb2Nlc3MgY29tbWFuZCBsaW5lIG9wdGlvbnMgKi8KIAlzZXJ2aWNl ID0gbm9uaW50ZXJhY3RpdmUgPSAwOwotCXdoaWxlICgobiA9IGdldG9wdChhcmdjLCBhcmd2LCAi YTpBOmNDOmREZmhsOm06bnI6U3N1OiIpKSAhPSAtMSkgeworCXdoaWxlICgobiA9IGdldG9wdChh cmdjLCBhcmd2LCAiYTpBOmNDOmREZmhsOm06bnI6UnNTdToiKSkgIT0gLTEpIHsKIAkJc3dpdGNo IChuKSB7CiAJCWNhc2UgJ2EnOgogCQkJaWYgKCFidF9hdG9uKG9wdGFyZywgJmNvbnRleHQucmFk ZHIpKSB7CkBAIC0xODAsNyArMTgwLDcgQEAKIAkJCWJyZWFrOwogCiAJCWNhc2UgJ2QnOiAvKiBk byBub3QgZGV0YWNoIHNlcnZlciAqLwotCQkJY29udGV4dC5kZXRhY2ggPSAwOworCQkJZGV0YWNo ID0gMDsKIAkJCWJyZWFrOwogCiAJCWNhc2UgJ0QnOiAvKiB1c2Ugc3RkaW4vc3Rkb3V0ICovCkBA IC0yMTcsNiArMjE3LDExIEBACiAJCQkJZXJyKDEsICJDb3VsZCBub3QgcmVhbHBhdGgoJXMpIiwg b3B0YXJnKTsKIAkJCWJyZWFrOwogCisJCWNhc2UgJ1InOiAvKiB2aXJ0dWFsaXplIHJvb3QgZm9y IGVhY2ggZGV2aWNlICovCisJCQljb250ZXh0LnZyb290ID0gMTsKKwkJCWNvbnRleHQuc2VjdXJl ID0gMTsKKwkJCWJyZWFrOworCiAJCWNhc2UgJ3MnOiAvKiBzZXJ2ZXIgKi8KIAkJCWlmIChub25p bnRlcmFjdGl2ZSkKIAkJCQl1c2FnZShiYXNlbmFtZShhcmd2WzBdKSk7CkBAIC0yNjksMjMgKzI3 NCwxMCBAQAogCWxvZ19vcGVuKCJvYmV4YXBwIiwgcHJpX25hbWUsIDApOwogCiAJLyogRGV0YWNo IHNlcnZlciAoaWYgcmVxdWlyZWQpICovCi0JaWYgKGNvbnRleHQuc2VydmVyICYmIGNvbnRleHQu ZGV0YWNoKSB7Ci0JCXBpZF90CXBpZCA9IGZvcmsoKTsKLQotCQlpZiAocGlkID09IChwaWRfdCkg LTEpIHsKLQkJCWxvZ19lcnIoIiVzKCk6IENvdWxkIG5vdCBmb3JrLiAlcyAoJWQpIiwKLQkJCQlf X2Z1bmNfXywgc3RyZXJyb3IoZXJybm8pLCBlcnJubyk7Ci0JCQlleGl0KDEpOwotCQl9Ci0KLQkJ aWYgKHBpZCAhPSAwKQotCQkJZXhpdCgwKTsKLQotCQlpZiAoZGFlbW9uKDAsIDApIDwgMCkgewot CQkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IGRhZW1vbi4gJXMgKCVkKSIsCi0JCQkJX19mdW5j X18sIHN0cmVycm9yKGVycm5vKSwgZXJybm8pOwotCQkJZXhpdCgxKTsKLQkJfQorCWlmIChjb250 ZXh0LnNlcnZlciAmJiBkZXRhY2ggJiYgZGFlbW9uKDAsIDApIDwgMCkgeworCQlsb2dfZXJyKCIl cygpOiBDb3VsZCBub3QgZGFlbW9uLiAlcyAoJWQpIiwKKwkJCV9fZnVuY19fLCBzdHJlcnJvcihl cnJubyksIGVycm5vKTsKKwkJZXhpdCgxKTsKIAl9CiAKIAkvKiBJbml0aWFsaXplIE9CRVggKi8K SW5kZXg6IG9iZXhhcHAuMQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvdXNyL2xvY2FsL2N2cy9wb3J0 cy9vYmV4YXBwL29iZXhhcHAuMSx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNQpkaWZmIC11IC1y MS4xNSBvYmV4YXBwLjEKLS0tIG9iZXhhcHAuMQkyMSBNYXkgMjAwNyAxNTo1NTozNSAtMDAwMAkx LjE1CisrKyBvYmV4YXBwLjEJMTMgQXByIDIwMDkgMjM6MTU6MDMgLTAwMDAKQEAgLTU0LDcgKzU0 LDcgQEAKIC5BciBwYXJhbWV0ZXJzCiAuTm0KIC5GbCBzCi0uT3AgRmwgZERTaAorLk9wIEZsIGRE U1JoCiAuT3AgRmwgQSBBciBCRF9BRERSCiAuRmwgQyBBciBjaGFubmVsCiAuT3AgRmwgbSBBciBN VFUKQEAgLTE5Myw2ICsxOTMsMTIgQEAKIERlZmF1bHRzIHRvIHRoZSBtYXhpbXVtIHN1cHBvcnRl ZCB2YWx1ZS4KIC5JdCBGbCBuIAogV29yayBpbiB0aGUgbm9uLWludGVyYWN0aXZlIGNsaWVudCBt b2RlLgorLkl0IEZsIFIKK1ZpcnR1YWxpemUgcm9vdCBmb2xkZXIgZm9yIGVhY2ggY2xpZW50IGRl dmljZSBpbiBzZXJ2ZXIgbW9kZS4KK1dpbGwgYXV0b21hdGljYWxseSB0dXJuIG9uIHNlY3VyZSBt b2RlLCBpLmUuCisuRmwgUworb3B0aW9uLgorUGxlYXNlIHJlYWQgc2VjdGlvbiBiZWxvdyBmb3Ig YSBjb21wbGV0ZSBkZXNjcmlwdGlvbi4KIC5JdCBGbCByIEFyIHBhdGgKIFNwZWNpZnkgcm9vdCBm b2xkZXIuCiBEZWZhdWx0IHJvb3QgZm9sZGVyIGluIHRoZSBzZXJ2ZXIgbW9kZSBpcwpAQCAtMjE2 LDYgKzIyMiw0MyBAQAogVGhlIHZhbHVlIHNwZWNpZmllZCBtYXkgYmUgZWl0aGVyIGEgdXNlcm5h bWUgb3IgYSBudW1lcmljIHVzZXIgaWQuCiBUaGlzIG9ubHkgd29ya3MgaWYgc2VydmVyIHdhcyBz dGFydGVkIGFzIHJvb3QuCiAuRWwKKy5TaCBWSVJUVUFMIFJPT1QgRk9MREVSUworV2hlbiBhY2Nl cHRpbmcgY29ubmVjdGlvbnMgaW4gc2VydmVyIG1vZGUsIAorLk5tCit3aWxsIGF0dGVtcHQgdG8g ZmluZCBhIHN1YmRpcmVjdG9yeSB0aGF0IHdvdWxkIGFjdCBhcyBhIHZpcnR1YWwgcm9vdAorZm9s ZGVyIGZvciB0aGUgY29ubmVjdGluZyBkZXZpY2UuCitWaXJ0dWFsIHJvb3QgZm9sZGVycyBtdXN0 IHJlc2lkZSB1bmRlciBkZWZhdWx0IHJvb3QgZm9sZGVyIHdoaWNoIGlzIHNldAord2l0aAorLkZs IHIKK29wdGlvbi4KK1RoZSBydWxlcyBhcmUgYXMgZm9sbG93czoKKy5CbCAtZW51bSAtb2Zmc2V0 IGluZGVudCAtY29tcGFjdAorLkl0CisuTm0KK3dpbGwgdHJ5IHRvIHJlc29sdmUgY29ubmVjdGlu ZyBkZXZpY2UncyBCRF9BRERSIHVzaW5nCisuWHIgYnRfZ2V0aG9zdGJ5YWRkciAzCitjYWxsIGFu ZCBjaGVjayBmb3IgYSBzdWJkaXJlY3RvcnkgdGhhdCBtYXRjaGVzIHJlc29sdmVkIG5hbWUgKGlm IGFueSk7CisuSXQKKy5ObQord2lsbCBjaGVjayBmb3IgYSBzdWJkaXJlY3RvcnkgdGhhdCBtYXRj aGVzIGNvbm5lY3RpbmcgZGV2aWNlJ3MgQkRfQUREUjsKKy5JdAorLk5tCit3aWxsIGNoZWNrIGZv ciBhIHN1YmRpcmVjdG9yeSwgbmFtZWQKKy5EcSBkZWZhdWx0IDsKKy5FbAorSWYgbm9uZSBvZiB0 aGUgYWJvdmUgbWF0Y2hlcywgdGhlbiB0aGUgY29ubmVjdGlvbiB0byB0aGUgY2xpZW50IGlzIHRl cm1pbmF0ZWQuCitPdGhlcndpc2UsCisuTm0KK3dpbGwgY2hhbmdlIGRlZmF1bHQgcm9vdCBmb2xk ZXIgdGhlIHRoZSBmb3VuZCBzdWJkaXJlY3RvcnkuCitUaGlzIGFsbG93cyB0aGUgc2FtZSBzeXN0 ZW0gdG8gaW50ZWxsaWdlbnRseSBkaXN0aW5ndWlzaCBkaWZmZXJlbnQKK2NsaWVudCBkZXZpY2Vz IGFzIGJlbG9uZ2luZyB0byBkaWZmZXJlbnQgdXNlcnMuCitBbiBhZG1pbmlzdHJhdG9yIGNhbiBz ZXQgdXAgdGhlIHN1YmRpcmVjdG9yaWVzIGZvcgora25vd24gZGV2aWNlcyB1bmRlcgorLlBhIC92 YXIvc3Bvb2wvb2JleAorKG9yIHdoZXJldmVyLCBzZWUKKy5GbCByCitvcHRpb24pIGZvciBlYWNo IHVzZXIsIG9yIGV2ZW4gYXMgc3ltbGlua3MgdG8gZWFjaCB1c2VyJ3MgaG9tZSBkaXJlY3RvcnkK KyhvciBhIHN1YmRpcmVjdG9yeSB0aGVyZW9mKS4KIC5TaCBMT0NBTEUgU1VQUE9SVAogVGhlCiAu Tm0KQEAgLTMyNSw2ICszNjgsMTMgQEAKIC5EdiBBTlkKIGFkZHJlc3MgYW5kIFJGQ09NTSBjaGFu bmVsCiAuTGkgMSAuCisuSXQgbG4gLXMgQXIgL2hvbWUvd2FsbGFieSBBciAvdmFyL3Nwb29sL29i ZXgvMDA6MDE6MDI6MDM6MDQ6MDUKKy5JdCBjaG93biAtaCB3YWxsYWJ5IEFyIC92YXIvc3Bvb2wv b2JleC8wMDowMTowMjowMzowNDowNQorV2hlbmV2ZXIgdGhlIGRldmljZSB3aXRoIEJEX0FERFIg b2YgMDA6MDE6MDI6MDM6MDQ6MDUgY29ubmVjdHMsCisuTm0KK3J1bm5pbmcgaW4gc2VydmVyIG1v ZGUgd2lsbCBzd2l0Y2ggdG8gdXNlciBJRAorLkFyIHdhbGxhYnkKK2FuZCB1c2UgdGhlaXIgaG9t ZSBkaXJlY3RvcnkgYXMgdGhlIHRvcC1sZXZlbCBmb3IgdGhlIGNvbm5lY3Rpb24uIAogLkVsCiAu U3MgTGV2ZWwgMSBJbmZvcm1hdGlvbiBBY2Nlc3MKIFRoZSBmaXJzdCBsZXZlbCBpbnZvbHZlcyB0 aGUgYmFzaWMgYWJpbGl0eSB0byBwdXQgYW4gb2JqZWN0IChzdWNoIGFzIGEgdkNhcmQpCkluZGV4 OiBvYmV4YXBwLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Vzci9sb2NhbC9jdnMvcG9ydHMvb2Jl eGFwcC9vYmV4YXBwLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuOQpkaWZmIC11IC1yMS45IG9i ZXhhcHAuaAotLS0gb2JleGFwcC5oCTIzIEFwciAyMDA3IDE4OjI5OjE4IC0wMDAwCTEuOQorKysg b2JleGFwcC5oCTEzIEFwciAyMDA5IDIxOjIyOjI5IC0wMDAwCkBAIC04Nyw4ICs4Nyw4IEBACiAJ dW5zaWduZWQJCSBzZXJ2ZXIgICAgIDogMTsgLyogc2VydmVyIG1vZGU/ICovCiAJdW5zaWduZWQJ CSBzZWN1cmUgICAgIDogMTsgLyogc2VjdXJlIG1vZGU/ICovCiAJdW5zaWduZWQJCSBkb25lICAg ICAgIDogMTsgLyogZG9uZT8gKi8KLQl1bnNpZ25lZAkJIGRldGFjaCAgICAgOiAxOyAvKiBkZXRh Y2ggc2VydmVyPyAqLwogCXVuc2lnbmVkIAkJIGZicyAgICAgICAgOiAxOyAvKiBGb2xkZXIgQnJv d3NpbmcgU2VydmljZSAqLworCXVuc2lnbmVkCQkgdnJvb3QJICAgIDogMTsgLyogdmlydHVhbGl6 ZSBkZXZpY2UncyByb290ICovCiAJdW5zaWduZWQJCSByZXNlcnZlZCAgIDogMjsKIAogCS8qIGxv Y2FsIFNEUCBzZXNzaW9uIChzZXJ2ZXIgb25seSkgKi8KSW5kZXg6IHNlcnZlci5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KUkNTIGZpbGU6IC91c3IvbG9jYWwvY3ZzL3BvcnRzL29iZXhhcHAvc2VydmVyLmMsdgpyZXRy aWV2aW5nIHJldmlzaW9uIDEuMTEKZGlmZiAtdSAtcjEuMTEgc2VydmVyLmMKLS0tIHNlcnZlci5j CTkgQXByIDIwMDkgMjM6MTY6MzEgLTAwMDAJMS4xMQorKysgc2VydmVyLmMJMTMgQXByIDIwMDkg MjM6MTA6MzEgLTAwMDAKQEAgLTEsNiArMSw4IEBACiAvKgogICogc2VydmVyLmMKLSAqCisgKi8K KworLyotCiAgKiBDb3B5cmlnaHQgKGMpIDIwMDIgTWFrc2ltIFlldm1lbmtpbiA8bV9ldm1lbmtp bkB5YWhvby5jb20+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogICoKQEAgLTg5LDYgKzkxLDEx IEBACiBzdGF0aWMgY2hhciBjb25zdCAqIGNvbnN0CWxzX3BhcmVudF9mb2xkZXIgPQogCSI8cGFy ZW50LWZvbGRlci8+XG4iOwogCitzdGF0aWMgaW50IG9iZXhhcHBfc2VydmVyX3NldF9yb290CisJ CShjb250ZXh0X3AgY29udGV4dCk7CitzdGF0aWMgaW50IG9iZXhhcHBfc2VydmVyX3NldF9kZXZp Y2Vfcm9vdAorCQkoY29udGV4dF9wIGNvbnRleHQpOworCiAvKiBPQkVYIHJlcXVlc3QgaGFuZGxl cnMgKi8KIHN0YXRpYyBvYmV4YXBwX3JlcXVlc3RfaGFuZGxlcl90CW9iZXhhcHBfc2VydmVyX3Jl cXVlc3RfY29ubmVjdDsKIHN0YXRpYyBvYmV4YXBwX3JlcXVlc3RfaGFuZGxlcl90CW9iZXhhcHBf c2VydmVyX3JlcXVlc3RfZGlzY29ubmVjdDsKQEAgLTExNCw3ICsxMjEsNiBAQAogb2JleGFwcF9z ZXJ2ZXIob2JleF90ICpoYW5kbGUpCiB7CiAJY29udGV4dF9wCQkgY29udGV4dCA9IChjb250ZXh0 X3ApIE9CRVhfR2V0VXNlckRhdGEoaGFuZGxlKTsKLQlzdHJ1Y3QgcGFzc3dkCQkqcHcgPSBOVUxM OwogCWludAkJCSBlcnJvciA9IC0xOwogCXN0cnVjdCBzb2NrYWRkcl9yZmNvbW0JIGFkZHI7CiAK QEAgLTEzMSwyNiArMTM3LDYgQEAKIAkJZ290byBkb25lOwogCX0KIAotCWlmIChjb250ZXh0LT51 c2VyICE9IE5VTEwpIHsKLQkJaWYgKGF0b2koY29udGV4dC0+dXNlcikgIT0gMCkKLQkJCXB3ID0g Z2V0cHd1aWQoYXRvaShjb250ZXh0LT51c2VyKSk7Ci0JCWVsc2UKLQkJCXB3ID0gZ2V0cHduYW0o Y29udGV4dC0+dXNlcik7Ci0KLQkJaWYgKHB3ID09IE5VTEwpIHsKLQkJCWxvZ19lcnIoIiVzKCk6 IFVua25vd24gdXNlciAlcyIsIF9fZnVuY19fLCAKLQkJCQljb250ZXh0LT51c2VyKTsKLQkJCWdv dG8gZG9uZTsKLQkJfQotCX0KLQotCWlmIChjb250ZXh0LT5yb290WzBdID09ICdcMCcpIHsKLQkJ aWYgKHB3ID09IE5VTEwpCi0JCQlzdHJsY3B5KGNvbnRleHQtPnJvb3QsIE9CRVhBUFBfUk9PVF9E SVIsIFBBVEhfTUFYKTsKLQkJZWxzZQotCQkJc3RybGNweShjb250ZXh0LT5yb290LCBwdy0+cHdf ZGlyLCBQQVRIX01BWCk7Ci0JfQotCiAJbG9nX2luZm8oIiVzOiBTdGFydGluZyBPQkVYIHNlcnZl ciIsIF9fZnVuY19fKTsKIAogCWlmIChPQkVYX1NldFRyYW5zcG9ydE1UVShoYW5kbGUsIGNvbnRl eHQtPm10dSwgY29udGV4dC0+bXR1KSA8IDApIHsKQEAgLTE2Miw3ICsxNDgsNyBAQAogCWFkZHIu cmZjb21tX2xlbiA9IHNpemVvZihhZGRyKTsKIAlhZGRyLnJmY29tbV9mYW1pbHkgPSBBRl9CTFVF VE9PVEg7CiAJYWRkci5yZmNvbW1fY2hhbm5lbCA9IGNvbnRleHQtPmNoYW5uZWw7Ci0JbWVtY3B5 KCZhZGRyLnJmY29tbV9iZGFkZHIsICZjb250ZXh0LT5yYWRkciwgc2l6ZW9mKGNvbnRleHQtPnJh ZGRyKSk7CisJbWVtY3B5KCZhZGRyLnJmY29tbV9iZGFkZHIsICZjb250ZXh0LT5sYWRkciwgc2l6 ZW9mKGNvbnRleHQtPmxhZGRyKSk7CiAKIAlpZiAoT0JFWF9TZXJ2ZXJSZWdpc3RlcihoYW5kbGUs IChzdHJ1Y3Qgc29ja2FkZHIgKikgJmFkZHIsCiAJCQlzaXplb2YoYWRkcikpIDwgMCkgewpAQCAt MTcwLDQwICsxNTYsOCBAQAogCQlnb3RvIGRvbmU7CiAJfQogCi0JaWYgKGdldHVpZCgpID09IDAp IHsKLQkJaWYgKGNvbnRleHQtPnNlY3VyZSkgewotCQkJaWYgKGNocm9vdChjb250ZXh0LT5yb290 KSA8IDApIHsKLQkJCQlsb2dfZXJyKCIlcygpOiBDb3VsZCBub3QgY2hyb290KCVzKS4gJXMgKCVk KSIsCi0JCQkJCV9fZnVuY19fLCBjb250ZXh0LT5yb290LAotCQkJCQlzdHJlcnJvcihlcnJubyks IGVycm5vKTsKLQkJCQlnb3RvIGRvbmU7Ci0JCQl9Ci0KLQkJCXN0cmxjcHkoY29udGV4dC0+cm9v dCwgIi8iLCBQQVRIX01BWCk7Ci0JCX0KLQotCQlpZiAocHcgIT0gTlVMTCkgewotCQkJaWYgKHNl dGdpZChwdy0+cHdfZ2lkKSA8IDApIHsKLQkJCQlsb2dfZXJyKCIlcygpOiBDb3VsZCBub3Qgc2V0 Z2lkKCVkKS4gJXMgKCVkKSIsCi0JCQkJCV9fZnVuY19fLCBwdy0+cHdfZ2lkLCBzdHJlcnJvcihl cnJubyksCi0JCQkJCWVycm5vKTsKLQkJCQlnb3RvIGRvbmU7Ci0JCQl9Ci0KLQkJCWlmIChzZXR1 aWQocHctPnB3X3VpZCkgPCAwKSB7Ci0JCQkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IHNldHVp ZCglZCkuICVzICglZCkiLAotCQkJCQlfX2Z1bmNfXywgcHctPnB3X3VpZCwgc3RyZXJyb3IoZXJy bm8pLAotCQkJCQllcnJubyk7Ci0JCQkJZ290byBkb25lOwotCQkJfQotCQl9Ci0JfQotCi0JaWYg KGNoZGlyKGNvbnRleHQtPnJvb3QpIDwgMCkgewotCQlsb2dfZXJyKCIlcygpOiBDb3VsZCBub3Qg Y2hkaXIoJXMpLiAlcyAoJWQpIiwKLQkJCV9fZnVuY19fLCBjb250ZXh0LT5yb290LCBzdHJlcnJv cihlcnJubyksIGVycm5vKTsKKwlpZiAob2JleGFwcF9zZXJ2ZXJfc2V0X3Jvb3QoY29udGV4dCkg PCAwKQogCQlnb3RvIGRvbmU7Ci0JfQogCiAJbG9nX2RlYnVnKCIlcygpOiBFbnRlcmluZyBldmVu dCBwcm9jZXNzaW5nIGxvb3AuLi4iLCBfX2Z1bmNfXyk7CiAKQEAgLTIyNyw2ICsxODEsMTU1IEBA CiB9IC8qIG9iZXhhcHBfc2VydmVyICovCiAKIC8qCisgKiBTZXQgc2VydmVyIHJvb3QKKyAqLwor CitpbnQKK29iZXhhcHBfc2VydmVyX3NldF9yb290KGNvbnRleHRfcCBjb250ZXh0KQoreworCXN0 cnVjdCBwYXNzd2QJKnB3OworCWNoYXIJCSplcDsKKwl1aWRfdAkJdWlkOworCisJaWYgKGNvbnRl eHQtPnVzZXIgIT0gTlVMTCkgeworCQl1aWQgPSBzdHJ0b3VsKGNvbnRleHQtPnVzZXIsICZlcCwg MTApOworCQlpZiAoKmVwICE9ICdcMCcpCisJCQlwdyA9IGdldHB3bmFtKGNvbnRleHQtPnVzZXIp OworCQllbHNlCisJCQlwdyA9IGdldHB3dWlkKHVpZCk7CisKKwkJaWYgKHB3ID09IE5VTEwpIHsK KwkJCWxvZ19lcnIoIiVzKCk6IFVua25vd24gdXNlciAlcyIsCisJCQkJX19mdW5jX18sIGNvbnRl eHQtPnVzZXIpOworCQkJcmV0dXJuICgtMSk7CisJCX0KKworCQlsb2dfZGVidWcoIiVzKCk6IFJl cXVlc3RlZCB0byBydW4gYXMgJyVzJyB1aWQ9JWQsIGdpZD0lZCIsCisJCQlfX2Z1bmNfXywgY29u dGV4dC0+dXNlciwgcHctPnB3X3VpZCwgcHctPnB3X2dpZCk7CisJfSBlbHNlCisJCXB3ID0gTlVM TDsKKworCS8qIFNldCBkZWZhdWx0IHJvb3QgKi8KKwlpZiAoY29udGV4dC0+cm9vdFswXSA9PSAn XDAnKSB7CisJCWlmIChwdyA9PSBOVUxMKQorCQkJc3RybGNweShjb250ZXh0LT5yb290LCBPQkVY QVBQX1JPT1RfRElSLCBQQVRIX01BWCk7CisJCWVsc2UKKwkJCXN0cmxjcHkoY29udGV4dC0+cm9v dCwgcHctPnB3X2RpciwgUEFUSF9NQVgpOworCX0KKworCWlmIChjaGRpcihjb250ZXh0LT5yb290 KSA8IDApIHsKKwkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IGNoZGlyKCVzKS4gJXMgKCVkKSIs CisJCQlfX2Z1bmNfXywgY29udGV4dC0+cm9vdCwgc3RyZXJyb3IoZXJybm8pLCBlcnJubyk7CisJ CXJldHVybiAoLTEpOworCX0KKworCS8qIFNldCBkZXZpY2Ugc3BlY2lmaWMgcm9vdCAqLworCWlm IChjb250ZXh0LT52cm9vdCAmJiBvYmV4YXBwX3NlcnZlcl9zZXRfZGV2aWNlX3Jvb3QoY29udGV4 dCkgPD0gMCkKKwkJcmV0dXJuICgtMSk7CisKKwlsb2dfZGVidWcoIiVzKCk6IFVzaW5nIHJvb3Qg JXMiLCBfX2Z1bmNfXywgY29udGV4dC0+cm9vdCk7CisKKwlpZiAoY29udGV4dC0+c2VjdXJlKSB7 CisJCWlmIChjaHJvb3QoY29udGV4dC0+cm9vdCkgPCAwKSB7CisJCQlsb2dfZXJyKCIlcygpOiBD b3VsZCBub3QgY2hyb290KCVzKS4gJXMgKCVkKSIsCisJCQkJX19mdW5jX18sIGNvbnRleHQtPnJv b3QsCisJCQkJc3RyZXJyb3IoZXJybm8pLCBlcnJubyk7CisJCQlyZXR1cm4gKC0xKTsKKwkJfQor CisJCXN0cmxjcHkoY29udGV4dC0+cm9vdCwgIi8iLCBQQVRIX01BWCk7CisKKwkJbG9nX2RlYnVn KCIlcygpOiBTZWN1cmUgbW9kZSBlbmFibGVkIiwgX19mdW5jX18pOworCX0KKworCWlmIChwdyAh PSBOVUxMKSB7CisJCWlmIChzZXRnaWQocHctPnB3X2dpZCkgPCAwKSB7CisJCQlsb2dfZXJyKCIl cygpOiBDb3VsZCBub3Qgc2V0Z2lkKCVkKS4gJXMgKCVkKSIsCisJCQkJX19mdW5jX18sIHB3LT5w d19naWQsIHN0cmVycm9yKGVycm5vKSwgZXJybm8pOworCQkJcmV0dXJuICgtMSk7CisJCX0KKwor CQlpZiAoc2V0dWlkKHB3LT5wd191aWQpIDwgMCkgeworCQkJbG9nX2VycigiJXMoKTogQ291bGQg bm90IHNldHVpZCglZCkuICVzICglZCkiLAorCQkJCV9fZnVuY19fLCBwdy0+cHdfdWlkLCBzdHJl cnJvcihlcnJubyksIGVycm5vKTsKKwkJCXJldHVybiAoLTEpOworCQl9CisKKwkJbG9nX2RlYnVn KCIlcygpOiBSdW5uaW5nIGFzIHVpZD0lZCwgZ2lkPSVkIiwKKwkJCV9fZnVuY19fLCBnZXR1aWQo KSwgZ2V0Z2lkKCkpOworCX0KKworCXJldHVybiAoMCk7Cit9IC8qIG9iZXhhcHBfc2VydmVyX3Nl dF9yb290ICovCisKKy8qCisgKiBTZXQgZGV2aWNlIHNwZWNpZmljIHNlcnZlciByb290CisgKi8K Kworc3RhdGljIGludAorb2JleGFwcF9zZXJ2ZXJfc2V0X2RldmljZV9yb290KGNvbnRleHRfcCBj b250ZXh0KQoreworCWNoYXIgY29uc3QJKnJvb3RbXSA9IHsgTlVMTCwgTlVMTCwgTlVMTCB9Owor CXN0cnVjdCBob3N0ZW50CSpoZTsKKwlzdHJ1Y3Qgc3RhdAlzYjsKKwlpbnQJCW47CisKKwluID0g MDsKKworCWhlID0gYnRfZ2V0aG9zdGJ5YWRkcigoY2hhciBjb25zdCAqKSAmY29udGV4dC0+cmFk ZHIsCisJCQlzaXplb2YoYmRhZGRyX3QpLCBBRl9CTFVFVE9PVEgpOworCWlmIChoZSAhPSBOVUxM KQorCQlyb290W24gKytdID0gKGNoYXIgY29uc3QgKikgaGUtPmhfbmFtZTsKKworCXJvb3RbbiAr K10gPSBidF9udG9hKCZjb250ZXh0LT5yYWRkciwgTlVMTCk7CisKKwlyb290W24gKytdID0gImRl ZmF1bHQiOworCisJZm9yIChuID0gMDsgbiA8IDM7IG4gKyspIHsKKwkJaWYgKHJvb3Rbbl0gPT0g TlVMTCkKKwkJCWJyZWFrOworCisJCWxvZ19kZWJ1ZygiJXMoKTogQ2hlY2tpbmcgZm9yICVzLyVz IHN1YmRpcmVjdG9yeSIsCisJCQlfX2Z1bmNfXywgY29udGV4dC0+cm9vdCwgcm9vdFtuXSk7CisK KwkJaWYgKHN0YXQocm9vdFtuXSwgJnNiKSA8IDApIHsKKwkJCWlmIChlcnJubyA9PSBFTk9FTlQp CisJCQkJY29udGludWU7CisKKwkJCWxvZ19lcnIoIiVzKCk6IENvdWxkIG5vdCBsc3RhdCglcy8l cykuICVzICglZCkiLAorCQkJCV9fZnVuY19fLCBjb250ZXh0LT5yb290LCByb290W25dLAorCQkJ CXN0cmVycm9yKGVycm5vKSwgZXJybm8pOworCisJCQlyZXR1cm4gKC0xKTsKKwkJfQorCisJCWlm ICghU19JU0RJUihzYi5zdF9tb2RlKSkgeworCQkJbG9nX2RlYnVnKCIlcygpOiBJZ25vcmluZyAl cy8lcy4gTm90IGEgZGlyZWN0b3J5IiwKKwkJCQlfX2Z1bmNfXywgY29udGV4dC0+cm9vdCwgcm9v dFtuXSk7CisJCQljb250aW51ZTsKKwkJfQorCisJCXN0cmxjYXQoY29udGV4dC0+cm9vdCwgIi8i LCBQQVRIX01BWCk7CisJCXN0cmxjYXQoY29udGV4dC0+cm9vdCwgcm9vdFtuXSwgUEFUSF9NQVgp OworCisJCWlmIChjaGRpcihyb290W25dKSA8IDApIHsKKwkJCWxvZ19lcnIoIiVzKCk6IENvdWxk IG5vdCBjaGRpciglcykuICVzICglZCkiLAorCQkJCV9fZnVuY19fLCBjb250ZXh0LT5yb290LCBz dHJlcnJvcihlcnJubyksCisJCQkJZXJybm8pOworCQkJcmV0dXJuICgtMSk7CisJCX0KKworCQly ZXR1cm4gKDEpOworCX0KKworCWxvZ19ub3RpY2UoIiVzKCk6IENvdWxkIG5vdCBzZXQgZGV2aWNl IHNwZWNpZmljIHJvb3QgZm9yIHRoZSBkZXZpY2UgIiBcCisJCSJiZGFkZHIgJXMgKCVzKSIsIF9f ZnVuY19fLCByb290WzFdLAorCQlyb290WzBdPyByb290WzBdIDogIi1uby1uYW1lLSIpOworCisJ cmV0dXJuICgwKTsKK30gLyogb2JleGFwcF9zZXJ2ZXJfc2V0X2RldmljZV9yb290ICovCisKKy8q CiAgKiBQcm9jZXNzIE9CRVhfRVZfUkVRSElOVCBldmVudAogICovCiAKQEAgLTU2NSw2ICs2Njgs MTUgQEAKIAkJCX0KIAkJfQogCisJCWlmIChjaG1vZChjb250ZXh0LT50ZW1wLCBTX0lSVVNSfFNf SVdVU1J8U19JUkdSUHxTX0lXR1JQKSA8IDApIHsKKwkJCWxvZ19lcnIoIiVzKCk6IENvdWxkIG5v dCBjaG1vZCglcykuICVzICglZCkiLAorCQkJCV9fZnVuY19fLCBjb250ZXh0LT50ZW1wLAorCQkJ CXN0cmVycm9yKGVycm5vKSwgZXJybm8pOworCisJCQljb2RlcyA9IG9iZXhhcHBfdXRpbF9lcnJu bzJyZXNwb25zZShlcnJubyk7CisJCQlnb3RvIGRvbmU7CisJCX0KKwogCQlpZiAocmVuYW1lKGNv bnRleHQtPnRlbXAsIGNvbnRleHQtPmZpbGUpIDwgMCkgewogCQkJbG9nX2VycigiJXMoKTogQ291 bGQgbm90IHJlbmFtZSglcywgJXMpLiAlcyAoJWQpIiwKIAkJCQlfX2Z1bmNfXywgY29udGV4dC0+ dGVtcCwKSW5kZXg6IHRyYW5zcG9ydC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC91c3IvbG9jYWwv Y3ZzL3BvcnRzL29iZXhhcHAvdHJhbnNwb3J0LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTMK ZGlmZiAtdSAtcjEuMTMgdHJhbnNwb3J0LmMKLS0tIHRyYW5zcG9ydC5jCTIxIE1heSAyMDA3IDE1 OjU1OjM1IC0wMDAwCTEuMTMKKysrIHRyYW5zcG9ydC5jCTEwIEFwciAyMDA5IDE4OjI2OjA4IC0w MDAwCkBAIC0yODAsNiArMjgwLDkgQEAKIAkJCQlyZXR1cm4gKC0xKTsKIAkJCX0KIAorCQkJbWVt Y3B5KCZjb250ZXh0LT5yYWRkciwgJmFkZHIucmZjb21tX2JkYWRkciwKKwkJCQlzaXplb2YoY29u dGV4dC0+cmFkZHIpKTsKKwogCQkJcmV0dXJuICgxKTsKIAkJfQogCkluZGV4OiB1dGlsLmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQpSQ1MgZmlsZTogL3Vzci9sb2NhbC9jdnMvcG9ydHMvb2JleGFwcC91dGlsLmMsdgpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMTQKZGlmZiAtdSAtcjEuMTQgdXRpbC5jCi0tLSB1dGlsLmMJ MTAgQXByIDIwMDkgMTc6MjY6MDMgLTAwMDAJMS4xNAorKysgdXRpbC5jCTEwIEFwciAyMDA5IDE4 OjA1OjIzIC0wMDAwCkBAIC00MjUsOSArNDI1LDcgQEAKIAkgKiBzdHJpbmcsIHNvIGFsd2F5cyBw YXNzIGEgY29weS4KIAkgKi8KIAotCXN0cm5jcHkobiwgbmFtZSwgc2l6ZW9mKG4pKTsKLQluW3Np emVvZihuKSAtIDFdID0gJ1wwJzsKLQorCXN0cmxjcHkobiwgbmFtZSwgc2l6ZW9mKG4pKTsKIAlz bnByaW50Zih0ZW1wLCB0ZW1wX3NpemUsICIlcy9YWFhYWFhYWCIsIGRpcm5hbWUobikpOwogCiAJ cmV0dXJuIChta3N0ZW1wKHRlbXApKTsK --0016361648b35dad720467783cb8-- From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 01:06:06 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BF301065670 for ; Tue, 14 Apr 2009 01:06:06 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 23C5F8FC13 for ; Tue, 14 Apr 2009 01:06:05 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 3298 invoked from network); 14 Apr 2009 00:39:24 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 00:39:23 -0000 Message-ID: <49E3DB35.4030601@aldan.algebra.com> Date: Mon, 13 Apr 2009 20:39:17 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Maksim Yevmenkin References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------000404000405070103000206" Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 01:06:06 -0000 This is a multi-part message in MIME format. --------------000404000405070103000206 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): > possible setup > > - create 'obex' user and 'obex' group > - create '/var/spool/obex' (or whatever you want for default root) > owned by 'obex' user/group > - user 'foo' creates ~/private directory under his home directory with > 0700 permissions > - admin setups 'obex' directory under foo's ~/private/ directory with > 0770 permissions, this directory is owned by 'obex' user. group is set > to foo's group > - admin setups symlink in /var/spool/obex/ called 'foo_cell' that > points to ~foo/private/obex > - admin adds entry in the /etc/bluetooth/hosts file to assign > 'foo_cell' foo's cell phone bd_addr > - admin run obexapp server as 'obexapp -s -r /var/spool/obex -R -u obex -C 1' > > every time foo's uses cell phone to send data to the obex server, the > data will end up in foo's ~/private/obex directory. > > please give it a try and let me know it works. > I think, Maksim's proposal is suboptimal, because the uploaded files end up owned by the new user obex, rather than the actual user (foo in the above example), which will make file-manipulations on the system itself more difficult (obex-owned will they not have 600 permissions?). It also necessitates creation of a new UID without the security benefit of having the daemon run under that UID permanently (but only switching after accepting each connection)... My proposal -- discussed with Maksim at length -- would *derive the user-ID from the ownership of the link*. The sample set up would then be as follows. Suppose, user named wallaby has a device with BD_ADDR 01:02:03:04:05:06. The user would create a subdirectory for their bluetooth files (or use something existing, like ~/Desktop/): wallaby@tasmania (11) mkdir ~/bluetooth root will then -- on wallaby's request -- tell obexapp about it: root@tasmania (111) ln -s ~wallaby/bluetooth /var/spool/obex/01:02:03:04:05:06 root@tasmania (112) chown -h wallaby ~wallaby/bluetooth /var/spool/obex/01:02:03:04:05:06 The second of the above root's lines is what will -- under my proposal -- tell obexapp-daemon, who shall own any files uploaded by the device. If started as root, instead of becoming 'obex', obexapp will become 'wallaby'... Upon accepting a connection, the server will do the same lookups as Maksim's version is doing, cd/chroot into the subdirectory, and setuid to the proper UID (such as wallaby's in this example). The attached patch can be dropped into /usr/ports/comms/obexapp/files/ . The only functionality still missing from it compared to Maksim's is the bt_gethostbyaddr(3) lookup -- only the numeric BD_ADDR is currently considered. This is not a significant difference between proposals, though... My proposal has other, not so significant differences -- it allows the BD_ADDR-entries in /var/spool/obex to be non-directories (files, broken links a'la /etc/make.conf, even sockets). Even if a chdir into such an entry fails, the ID of the entry's owner will still be used to determine, which user shall own any uploaded files, etc. even though all such files will end up in the same directory (as they do with the current version of obexapp). Maksim thought, offering such flexibility would be too confusing... I agree, that chroot-ing (rather than merely chdir-ing) into such a "virtual root" directory makes sense. The only material difference between our proposals is my deriving the desired UID from the ownership of the found BD_ADDR entry vs. Maksim's always using the user specified on command-line (such as 'obex'). Yours, -mi --------------000404000405070103000206 Content-Type: text/plain; name="patch-uid" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-uid" --- obexapp.1 2007-05-21 11:55:35.000000000 -0400 +++ obexapp.1 2009-04-09 22:15:22.000000000 -0400 @@ -217,4 +217,30 @@ This only works if server was started as root. .El +.Sh Per-user configurations +When accepting connections in server mode, +.Nm +will check, if there is an entry named after the connecting device's +BD_ADDR in the root-path (default or specified by the +.Fl r +option). If found, the entry will be used as follows: +.Bl -enum -offset indent -compact +.It +The group ID will be changed to that, which owns the entry. +.It +If +.Nm +is running as root, it will change to the user, that owns the entry. +.It +If the entry is itself a directory and chdir into it succeeds, it will +be used as the top-level. +.El +This allows the same system to intelligently distinguish different Bluetooth devices +as belonging to different users. An administrator can set up the subdirectories for +known devices under +.Pa /var/spool/obex +(or wherever, see +.Fl r +option) for each user, or even as symlinks to each user's home directory +(or a subdirectory thereof). .Sh LOCALE SUPPORT The @@ -326,4 +352,11 @@ address and RFCOMM channel .Li 1 . +.It ln -s Ar /home/wallaby Ar /var/spool/obex/00:01:02:03:04:05 +.It chown -h wallaby Ar /var/spool/obex/00:01:02:03:04:05 +Whenever the device with BD_ADDR of 00:01:02:03:04:05 connects, +.Nm +running in server mode will switch to user ID +.Ar wallaby +and use their home directory as the top-level for the connection. .El .Ss Level 1 Information Access --- transport.c 2007-05-21 11:55:35.000000000 -0400 +++ transport.c 2009-04-09 20:53:27.000000000 -0400 @@ -271,4 +272,7 @@ addr.rfcomm_channel, getpid()); + memcpy(&context->raddr, &addr.rfcomm_bdaddr, + sizeof(context->raddr)); + if (daemon(1, 0) < 0) { log_err("%s(): Could not daemon. %s (%d)", --- work/obexapp/server.c 2009-04-10 12:29:53.000000000 -0400 +++ work/obexapp/server.c 2009-04-13 20:33:16.000000000 -0400 @@ -110,5 +110,4 @@ * OBEX server */ - int obexapp_server(obex_t *handle) @@ -118,4 +117,8 @@ int error = -1; struct sockaddr_rfcomm addr; + struct stat sb; + const char *subdir = bt_ntoa(&context->raddr, NULL); + uid_t uid = 0; + gid_t gid = getgid(); context->ss = sdp_open_local(NULL); @@ -143,4 +146,6 @@ goto done; } + uid = pw->pw_uid; + gid = pw->pw_gid; } @@ -171,4 +176,36 @@ } + if (chdir(context->root) < 0) { + log_err("%s(): Could not chdir(%s). %s (%d)", + __func__, context->root, strerror(errno), errno); + goto done; + } + + log_debug("%s(): checking for %s/%s subdirectory", __func__, + context->root, subdir); + if (lstat(subdir, &sb) == 0) { + log_debug("%s(): %s/%s exists and belongs to uid %d", + __func__, context->root, subdir, sb.st_uid); + uid = sb.st_uid; + gid = sb.st_gid; + if (chdir(subdir)) + log_debug("%s(): chdir to %s failed: %s. Will remain " + "on top (uid %ld).", __func__, subdir, strerror(errno), + (long)uid); + else + getwd(context->root); + + log_debug("%s(): using %s", __func__, context->root); + } else switch (errno) { + case ENOENT: + log_debug("%s(): %s/%s not found", __func__, + context->root, subdir); + break; + default: + log_err("%s(): %s/%s: %s", __func__, context->root, subdir, + strerror(errno)); + goto done; + } + if (getuid() == 0) { if (context->secure) { @@ -183,25 +220,19 @@ } - if (pw != NULL) { - if (setgid(pw->pw_gid) < 0) { - log_err("%s(): Could not setgid(%d). %s (%d)", - __func__, pw->pw_gid, strerror(errno), - errno); - goto done; - } - - if (setuid(pw->pw_uid) < 0) { + if (uid) { + if (setuid(uid) < 0) { log_err("%s(): Could not setuid(%d). %s (%d)", - __func__, pw->pw_uid, strerror(errno), + __func__, uid, strerror(errno), errno); goto done; } } - } - if (chdir(context->root) < 0) { - log_err("%s(): Could not chdir(%s). %s (%d)", - __func__, context->root, strerror(errno), errno); - goto done; + if (gid != getgid() && setgid(gid) < 0) { + log_err("%s(): Could not setgid(%d). %s (%d)", + __func__, gid, strerror(errno), + errno); + goto done; + } } --------------000404000405070103000206-- From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 02:10:00 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0738106564A for ; Tue, 14 Apr 2009 02:10:00 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3D68FC17 for ; Tue, 14 Apr 2009 02:10:00 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so302392gxk.19 for ; Mon, 13 Apr 2009 19:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ADkFPWeOj86Bg4KUWEiIHzIfq/poE+WAK8pbHNGIOHE=; b=lSSeQjO+7fRcTuVv70sNCXVmD/DW3MahY/jBb2P8PYrNQ9FUP7meUvvnXuyzySdpVS ZrF2KqU157m5P6yAwdLi2vKYHWJ5zFH/wdwNKcjM4NAfmw21lZDTygTEMZZBbbJrSD1I PWKq+mmzupIYC6xTs0S9OxUsz1wbuTe200GMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lYJwXhqpVXivVhHf/WltRiBkJC+nfQp/L+8OtqwIF9LtP+uXVzh4PucEcynkT6Lla7 Gy2037UhfwZGDuy1Mj4cRryrvC+gx0QlqB8n06xgbR7PWKrxDqtDHMVgxYlkRj/EHBye p/MGjJtTYGGAJ0JGpNkn74pR/s6jw1VFlzg8Q= MIME-Version: 1.0 Received: by 10.90.88.16 with SMTP id l16mr9096759agb.112.1239674999058; Mon, 13 Apr 2009 19:09:59 -0700 (PDT) In-Reply-To: <49E3DB35.4030601@aldan.algebra.com> References: <49E3DB35.4030601@aldan.algebra.com> Date: Mon, 13 Apr 2009 19:09:58 -0700 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 02:10:00 -0000 2009/4/13 Mikhail T. : > Maksim Yevmenkin =CE=C1=D0=C9=D3=C1=D7(=CC=C1): >> possible setup >> >> - create 'obex' user and 'obex' group >> - create '/var/spool/obex' (or whatever you want for default root) >> owned by 'obex' user/group >> - user 'foo' creates ~/private directory under his home directory with >> 0700 permissions >> - admin setups 'obex' directory under foo's ~/private/ directory with >> 0770 permissions, this directory is owned by 'obex' user. group is set >> to foo's group >> - admin setups symlink in /var/spool/obex/ called 'foo_cell' that >> points to ~foo/private/obex >> - admin adds entry in the /etc/bluetooth/hosts file to assign >> 'foo_cell' foo's cell phone bd_addr >> - admin run obexapp server as 'obexapp -s -r /var/spool/obex -R -u obex = -C 1' >> >> every time foo's uses cell phone to send data to the obex server, the >> data will end up in foo's ~/private/obex directory. >> >> please give it a try and let me know it works. >> > I think, Maksim's proposal is suboptimal, because the uploaded files end > up owned by the new user obex, rather than the actual user (foo in the > above example), which will make file-manipulations on the system itself > more difficult (obex-owned will they not have 600 permissions?). It also permissions on files will be set to 0660. > necessitates creation of a new UID without the security benefit of > having the daemon run under that UID permanently (but only switching > after accepting each connection)... i beg to differ. main process (the one that accepts connection) is running with elevated privileges, yes. however, the process that handles the actual connection from the client is running with reduced privileges. so, there is a security benefit. also, obexapp will chroot into virtual root. > My proposal -- discussed with Maksim at length -- would *derive the > user-ID from the ownership of the link*. The sample set up would then be > as follows. Suppose, user named wallaby has a device with BD_ADDR > 01:02:03:04:05:06. The user would create a subdirectory for their > bluetooth files (or use something existing, like ~/Desktop/): as i tried to explain, there are few problems (imo) with your patch. one example: what happens when remote client decides to create a directory which matches another client's bd_addr or name? i also do not like the fact that client are allowed to "escape" from their virtual root directory. another thing is that you pretty much force new behavior and not giving any control to disable it. what is worse, new behavior is controlled by file system elements which remote clients can potentially see, create and/or modify. [...] > My proposal has other, not so significant differences -- it allows the > BD_ADDR-entries in /var/spool/obex to be non-directories (files, broken > links a'la /etc/make.conf, even sockets). Even if a chdir into such an > entry fails, the ID of the entry's owner will still be used to > determine, which user shall own any uploaded files, etc. even though all > such files will end up in the same directory (as they do with the > current version of obexapp). > > Maksim thought, offering such flexibility would be too confusing... please explain what does it buy you exactly? so, great, you can control file ownership in the _same_ directory. like i said, unless you set sticky bit on the directory (which is evil, imo) and make it 0777 there is still a problem with sharing files (either obexapp running under new id won't be able to write to the root directory or everybody will be able to delete each others files). either way, its not that different from what obexapp does right now. > I agree, that chroot-ing (rather than merely chdir-ing) into such a > "virtual root" directory makes sense. The only material difference > between our proposals is my deriving the desired UID from the ownership > of the found BD_ADDR entry vs. Maksim's always using the user specified > on command-line (such as 'obex'). i'm actually not feeling very strongly about this. my initial choice is to be on a safe side. basically, what i'm trying to guard against is when someone put a symlink owned by root into the obexapp root folder. this is very easy thing to do, imo. i personally did it :) basically this type of misconfiguration will make obexapp continue to run with elevated privileges while servicing clients requests and that is a 'bad thing (tm)' :) i also must say that we are trying to solve the problem at the wrong level. more specifically, for phone book back up you probably want to use something else (like sync-ml for example) not not obexapp. bluetooth obex profiles are just completely oblivious to the fact that clients might need to supply credentials. its all strictly personal. so what i did, it basically provided mechanism to extend it in a similar manner. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 05:23:10 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFBD9106566B for ; Tue, 14 Apr 2009 05:23:10 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 30BD58FC08 for ; Tue, 14 Apr 2009 05:23:09 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 15884 invoked from network); 14 Apr 2009 05:23:09 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 05:23:09 -0000 Message-ID: <49E41DBB.5090805@aldan.algebra.com> Date: Tue, 14 Apr 2009 01:23:07 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Maksim Yevmenkin References: <49E3DB35.4030601@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 05:23:11 -0000 Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): >> I think, Maksim's proposal is suboptimal, because the uploaded files end >> up owned by the new user obex, rather than the actual user (foo in the >> above example), which will make file-manipulations on the system itself >> more difficult (obex-owned will they not have 600 permissions?). It also >> > permissions on files will be set to 0660. > I didn't see, where you do this -- simply using mkstemp will result in 600. But it can be done, of course. However, it is still imperfect, because all of the bluetooth users would have to be listed in obex' group and so there can be no more than 20 of them (I think, that's the limit on a group size). In any case, being owned by the actual user seems far more straightforward... >> necessitates creation of a new UID without the security benefit of >> having the daemon run under that UID permanently (but only switching >> after accepting each connection)... >> > i beg to differ. main process (the one that accepts connection) is > running with elevated privileges, yes. >From the security standpoint, this negates all/most benefits of having a dedicated UID for the service. The security people will tell you, that, as long as the root-owned process is always running and listening to connections, it can some day be fooled and so they don't like it anyway. > however, the process that > handles the actual connection from the client is running with reduced > privileges. so, there is a security benefit. It will drop the root-privileges under my proposal as well. It is just that the new UID will be that of the connecting user as determined by the BD_ADDR match, if such a match can be found. Otherwise, yes, it should become whatever user is specified with the -u switch. > also, obexapp will chroot > into virtual root. > Yes, I agree, this is advantageous. > i'm actually not feeling very strongly about this. my initial choice > is to be on a safe side. basically, what i'm trying to guard against > is when someone put a symlink owned by root into the obexapp root > folder. this is very easy thing to do, imo. i personally did it :) > The only thing I do feel strongly about, is that, when a matching directory entry is found, the server shall perform a setuid not to the generic 'obex' user, but to the owner of that entry (and chroot into it, yes). I do not think, you should give special meaning to entry named "default" -- because that would require special handling of the case, when somebody's BD_ADDR resolves to name "default". I'd say, it is Ok, if no match for the device is found, to remain in the top-level directory (after dropping the root-privileges). But, again, no strong feeling about this. My other ideas (such as the matching entries not necessarily being subdirectories) came from trying to maintain compatibility with the current operations (where everything lives in the same directory), while still allowing the created files to belong to different, cooperating users. > basically this type of misconfiguration will make obexapp continue to > run with elevated privileges while servicing clients requests and that > is a 'bad thing (tm)' :) > I agree, that continuing to run as root after accepting connection is bad -- if a matching entry is not found, the server, indeed, ought to setuid to some non-root user (as set by the -u switch or determined from the ownership of the top-level itself). However, the above-mentioned cooperation may still have its uses for some people. That said, they can have all their BD_ADDR symlinks point to the same directory and cooperate there, so I don't feel strongly about it either. > i also must say that we are trying to solve the problem at the wrong > level. more specifically, for phone book back up you probably want to > use something else (like sync-ml for example) not not obexapp. > Not sure, what "sync-ml" is (there is no such port). But what about dropping camera's pictures and videos? People would certainly expect to be able to do that straight from their devices (rather than by running a client of some sort), and find the files somewhere under their home directories (perhaps in ~/Desktop). So, I agree with most of your change, except the UID part -- in case a subdirectory-entry with a matching name is found, the argument of the setuid() (and setgid()) call should be the UID (and GID) of the entry (as determined by lstat(2), not stat(2), though). Yours, -mi From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 16:16:48 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DD9910656DF for ; Tue, 14 Apr 2009 16:16:48 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id BA9128FC13 for ; Tue, 14 Apr 2009 16:16:47 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1LtlJS-0004TH-Fy; Tue, 14 Apr 2009 17:16:42 +0100 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17074-04; Tue, 14 Apr 2009 17:16:42 +0100 (BST) Received: from [10.214.38.215] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1LtlJO-0004T3-2h; Tue, 14 Apr 2009 17:16:41 +0100 Received: (nullmailer pid 928 invoked by uid 1000); Tue, 14 Apr 2009 16:15:23 -0000 Date: Tue, 14 Apr 2009 17:15:23 +0100 (BST) To: "Mikhail T\." In-Reply-To: <49E41DBB.5090805@aldan.algebra.com> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1239725723.321671.1132.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 16:16:50 -0000 On Tue, 14 Apr 2009, Mikhail T. wrote: > > i beg to differ. main process (the one that accepts connection) is > > running with elevated privileges, yes. > >From the security standpoint, this negates all/most benefits of having a > dedicated UID for the service. The security people will tell you, that, I agree too, its not good to run a daemon (that can be accessed over a radio link and create/modify files no less) as root. > I agree, that continuing to run as root after accepting connection is > bad -- if a matching entry is not found, the server, indeed, ought to > setuid to some non-root user (as set by the -u switch or determined from > the ownership of the top-level itself). However, the above-mentioned > cooperation may still have its uses for some people. That said, they can > have all their BD_ADDR symlinks point to the same directory and > cooperate there, so I don't feel strongly about it either. If you did that, it would I think be better to have the bdaddr mapping in a config file. Symlinks are too much trouble. On the other hand, I'm not keen on config files either :) Also, it could be better in that case to have a master daemon (along the lines of inetd) that could accept connectins and start obex according to the remote device address. Thats perhaps a lot of work though. > > i also must say that we are trying to solve the problem at the wrong > > level. more specifically, for phone book back up you probably want to > > use something else (like sync-ml for example) not not obexapp. > > > Not sure, what "sync-ml" is (there is no such port). Try "msynctool" which uses libopensync, it has a pluggable API for different sync protocols (syncml is Nokia, synce is Windows) and is run from the computer end so you wouldn't have any issues with incoming files. > But what about dropping camera's pictures and videos? People would > certainly expect to be able to do that straight from their devices > (rather than by running a client of some sort), and find the files > somewhere under their home directories (perhaps in ~/Desktop). Do you want to send pictures to your account when your wife is logged in, or does she want to when you are logged in? I don't know what prior art is there, but it seems to me that (as I said before) the person logged in at the console owns the machine and should receive files being sent. As Max said, Bluetooth is not big on credentials, it is assumed that all users (normally a only one) have equal access. For this reason, Bluetooth cannot properly be a multi-user link unless all the users trust each other (while Alice is sending files to the computer, Bill could be checking her phone log) so I don't see a problem with having all the files in a master directory owned by the same user (but setting the default path per remote device seems a good compromise) regards, iain From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 16:34:44 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE350106566C for ; Tue, 14 Apr 2009 16:34:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8113E8FC13 for ; Tue, 14 Apr 2009 16:34:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1559890ywh.13 for ; Tue, 14 Apr 2009 09:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xK1uu6vIRCFUP0MjJ/+7KtEN1LfmnVzvccnSh9e0jvs=; b=iK3IOQEd+upPRK3T2ee1YahXKUpVqP2hQicNEHT3dhIFkxhGhy4YgQeConBc7x9gFh Tqvm8xw8RsOeLETk9EwPjGKN3AlqmJHi+vdyD9BFnvNN957AcLuC324+CMk+uWUgEYLd 2YOHJVXdiplw5T6xAy7tBiJ32XRKwsy/KGCag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Puq5pIGDgcYvClLwP56QNXbCEfnkyLlvun8J+3T6ttRC0xZ654FiojYnesQr3c8rUG c6uhoOB33yVniJ/EOVfnEvY/5lTlABscHB1vw1WhP5Zp08w2ibzz0gvahojuKzg2sHk/ JP/2Xu/AH5bS6Sv9h/6iGOMCYHC1r6sRfI9AU= MIME-Version: 1.0 Received: by 10.90.49.8 with SMTP id w8mr9928304agw.101.1239726883657; Tue, 14 Apr 2009 09:34:43 -0700 (PDT) In-Reply-To: <49E41DBB.5090805@aldan.algebra.com> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> Date: Tue, 14 Apr 2009 09:34:43 -0700 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 16:34:45 -0000 2009/4/13 Mikhail T. : > Maksim Yevmenkin =CE=C1=D0=C9=D3=C1=D7(=CC=C1): >>> I think, Maksim's proposal is suboptimal, because the uploaded files en= d >>> up owned by the new user obex, rather than the actual user (foo in the >>> above example), which will make file-manipulations on the system itself >>> more difficult (obex-owned will they not have 600 permissions?). It als= o >>> >> permissions on files will be set to 0660. >> > I didn't see, where you do this -- simply using mkstemp will result in > 600. But it can be done, of course. However, it is still imperfect, perhaps you should take a closer look at the patch i posted? :-) in server.= c @@ -565,6 +668,15 @@ } } + if (chmod(context->temp, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP) < 0) { + log_err("%s(): Could not chmod(%s). %s (%d)", + __func__, context->temp, + strerror(errno), errno); + + codes =3D obexapp_util_errno2response(errno); + goto done; + } + > because all of the bluetooth users would have to be listed in obex' > group and so there can be no more than 20 of them (I think, that's the > limit on a group size). not really, as i said in my original email user's private obex directory is owned by 'obex' user, but the group is still set to the user's group and permissions are set to 0770. > In any case, being owned by the actual user seems far more > straightforward... its all about security vs. usability to me :) please read below. >>> necessitates creation of a new UID without the security benefit of >>> having the daemon run under that UID permanently (but only switching >>> after accepting each connection)... >>> >> i beg to differ. main process (the one that accepts connection) is >> running with elevated privileges, yes. > > From the security standpoint, this negates all/most benefits of having a > dedicated UID for the service. The security people will tell you, that, > as long as the root-owned process is always running and listening to > connections, it can some day be fooled and so they don't like it anyway. i'm having a hard time follow this part of the argument. both patches (yours and mine) will accept connection with elevated privileges. there is absolutely no difference here. so, i'm going to dismiss this part of the argument, sorry :) >> however, the process that >> handles the actual connection from the client is running with reduced >> privileges. so, there is a security benefit. > > It will drop the root-privileges under my proposal as well. It is just > that the new UID will be that of the connecting user as determined by > the BD_ADDR match, if such a match can be found. Otherwise, yes, it > should become whatever user is specified with the -u switch. if you are arguing that having separate 'obex' user provides no security benefits, then i disagree. and here is why. to me security is about managing the risks. i have to assume that someone will break into someone's system using obexapp as attack vector. so, lets see what happens in this case (1) when obexapp is running as separate user 'obex' in chroot()ed environment, the question is: what kind of damage 'obex' user can do in chroot()ed environment? (2) when obexapp is running as potentially _any_ user in the system in _unrestricted_ environment, the question is: what kind of damage _any_ user can do while roaming free? keep in mind that 'bad guy' can populate his environment with all kind of files before obtaining shell. now, please put on your security person's hat and tell me honestly which option would you choose? >> i'm actually not feeling very strongly about this. my initial choice >> is to be on a safe side. basically, what i'm trying to guard against >> is when someone put a symlink owned by root into the obexapp root >> folder. this is very easy thing to do, imo. i personally did it :) >> > The only thing I do feel strongly about, is that, when a matching > directory entry is found, the server shall perform a setuid not to the > generic 'obex' user, but to the owner of that entry (and chroot into it, > yes). like i said, its security vs. usability. i probably can live with chroot()ing and changing uid to owner of the directory (and _not_ symlink). > I do not think, you should give special meaning to entry named "default" > -- because that would require special handling of the case, when > somebody's BD_ADDR resolves to name "default". I'd say, it is Ok, if no > match for the device is found, to remain in the top-level directory > (after dropping the root-privileges). But, again, no strong feeling > about this. i'm willing to take my chances of this one :) its strictly local configuration and if someone has, in fact, named his/her bluetooth gadget 'default' then its too bad :) i'm also not keen of keeping 'default' name. it can be anything, like '00:00:00:00:00:00' or whatever. > My other ideas (such as the matching entries not necessarily being > subdirectories) came from trying to maintain compatibility with the > current operations (where everything lives in the same directory), while > still allowing the created files to belong to different, cooperating user= s. no, just put new behavior under separate option and keep it disabled by default. >> basically this type of misconfiguration will make obexapp continue to >> run with elevated privileges while servicing clients requests and that >> is a 'bad thing (tm)' :) >> > I agree, that continuing to run as root after accepting connection is > bad -- if a matching entry is not found, the server, indeed, ought to > setuid to some non-root user (as set by the -u switch or determined from > the ownership of the top-level itself). However, the above-mentioned > cooperation may still have its uses for some people. That said, they can > have all their BD_ADDR symlinks point to the same directory and > cooperate there, so I don't feel strongly about it either. the 'default' virtual root stays. remote clients have no business to see, know about and/or try to mess with other clients virtual roots. not sure if you noticed, but 'default' virtual root can be also considered as another level of access. basically, if there is no 'default' virtual root, clients without virtual root won't be able to access the server. broken symlinks is a bad idea, imo. i still do not get what do you gain by changing ownership on files in the same directory. perhaps i'm missing something here. please give me an example. >> i also must say that we are trying to solve the problem at the wrong >> level. more specifically, for phone book back up you probably want to >> use something else (like sync-ml for example) not not obexapp. >> > Not sure, what "sync-ml" is (there is no such port). But what about there is something called multisync (or something like that) but it needs freebsd bluetooth plugin. basically sync-ml is a xml based protocol that runs over obex and is used for synchronizing objects on systems. > dropping camera's pictures and videos? People would certainly expect to > be able to do that straight from their devices (rather than by running a > client of some sort), and find the files somewhere under their home > directories (perhaps in ~/Desktop). sure and they can do it. > So, I agree with most of your change, except the UID part -- in case a > subdirectory-entry with a matching name is found, the argument of the > setuid() (and setgid()) call should be the UID (and GID) of the entry > (as determined by lstat(2), not stat(2), though). like i said, its probably ok to change uid to owner of the _directory_ and chroot() into it. but lstat(2) is out, sorry :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 17:07:14 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53C4D1065758 for ; Tue, 14 Apr 2009 17:07:14 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 04E2A8FC21 for ; Tue, 14 Apr 2009 17:07:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1572264yxm.13 for ; Tue, 14 Apr 2009 10:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yOA6kEvQFv5hJuCmHVpSYFOzIBiKtx9zdEbsYmrdSAg=; b=ZNGeqKPwBO7cvQz4rT3L66OmJnvvOR/O+OFCbna/9/m/DggxcdLBtwxp3OTIcg6MIL DXkhOiH1LIeprPVF1LnNOf4EPT98HyfbqhfIS0fM2FI//kbRdLue3WhlTCn9oPFxpqiQ OKSIxJhopoT95A+7pzxE9Ww9qRKjW0DHQCD8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=anAvSJ4Rqu9GrOdkZCQltN3h0jWQejCEW0qURe2ciPMBqE26GdGclAYcmmeESnlhI4 mWcG2FkjjpbpyodxPeg58w/XGx4DbIb97JRT8YsZQ6MKxMZTYRKiiaz9R0mNRQ/wuCZS in65ssxUHwX3TFNFBsegjEQgawqKqO4N5tyZo= MIME-Version: 1.0 Received: by 10.90.105.17 with SMTP id d17mr10033325agc.92.1239728833310; Tue, 14 Apr 2009 10:07:13 -0700 (PDT) In-Reply-To: <1239725723.321671.1132.nullmailer@galant.ukfsn.org> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <1239725723.321671.1132.nullmailer@galant.ukfsn.org> Date: Tue, 14 Apr 2009 10:07:12 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "Mikhail T." Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:07:15 -0000 On Tue, Apr 14, 2009 at 9:15 AM, Iain Hibbert wrote: > On Tue, 14 Apr 2009, Mikhail T. wrote: > >> > i beg to differ. main process (the one that accepts connection) is >> > running with elevated privileges, yes. >> >From the security standpoint, this negates all/most benefits of having a >> dedicated UID for the service. The security people will tell you, that, > > I agree too, its not good to run a daemon (that can be accessed over a > radio link and create/modify files no less) as root. its only to call accept() and fork(). child process drops privileges right after that. in fact, i believe, there is no network i/o performed while child is running with elevated privileges. so, the window is small here. >> I agree, that continuing to run as root after accepting connection is >> bad -- if a matching entry is not found, the server, indeed, ought to >> setuid to some non-root user (as set by the -u switch or determined from >> the ownership of the top-level itself). However, the above-mentioned >> cooperation may still have its uses for some people. That said, they can >> have all their BD_ADDR symlinks point to the same directory and >> cooperate there, so I don't feel strongly about it either. > > If you did that, it would I think be better to have the bdaddr mapping in > a config file. Symlinks are too much trouble. On the other hand, I'm not > keen on config files either :) as i suggested, in private email, something like apache's .htaccess mechanism would be an ultimate solution here. however, its way too much complicated for what obexapp is :-) > Also, it could be better in that case to have a master daemon (along the > lines of inetd) that could accept connectins and start obex according to > the remote device address. Thats perhaps a lot of work though. that's, actually, an interesting idea. i could see how it could be applied to almost any bluetooth service. its not that much work, imo. obexapp already can use stdin/out as file descriptors (in client mode). configuration aspect of it is a pain though. perhaps we should think along the lines of bluetooth inetd that maps pair (protocol, protocol parameters) to service? something like (l2cap, 1) -> sdpd, (rfcomm, 1) -> obexapp, (rfcomm, 3) -> rfcomm_pppd etc.? >> But what about dropping camera's pictures and videos? People would >> certainly expect to be able to do that straight from their devices >> (rather than by running a client of some sort), and find the files >> somewhere under their home directories (perhaps in ~/Desktop). > > Do you want to send pictures to your account when your wife is logged in, > or does she want to when you are logged in? I don't know what prior art > is there, but it seems to me that (as I said before) the person logged in > at the console owns the machine and should receive files being sent. As > Max said, Bluetooth is not big on credentials, it is assumed that all > users (normally a only one) have equal access. > > For this reason, Bluetooth cannot properly be a multi-user link unless all > the users trust each other (while Alice is sending files to the computer, > Bill could be checking her phone log) so I don't see a problem with having > all the files in a master directory owned by the same user (but setting > the default path per remote device seems a good compromise) yes, that is what i was thinking too. its pretty much like running multiple copies of obexapp without actually running multiple copies of obexapp :) thanks, max > > regards, > iain > > From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 17:41:56 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76735106567C for ; Tue, 14 Apr 2009 17:41:56 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9C78FC20 for ; Tue, 14 Apr 2009 17:41:55 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 19037 invoked from network); 14 Apr 2009 17:41:55 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 17:41:54 -0000 Message-ID: <49E4CAE1.6090506@aldan.algebra.com> Date: Tue, 14 Apr 2009 13:41:53 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Maksim Yevmenkin References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:42:01 -0000 Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): > 2009/4/13 Mikhail T. : > > not really, as i said in my original email user's private obex > directory is owned by 'obex' user, but the group is still set to the > user's group and permissions are set to 0770. Even if the GID of the files will be that of the user, it being owned by obex will cause inconvenience. > i'm having a hard time follow this part of the argument. both patches > (yours and mine) will accept connection with elevated privileges. > there is absolutely no difference here. so, i'm going to dismiss this > part of the argument, sorry :) > You are absolutely correct, that there is no security difference between our approaches, when a matching BD_ADDR entry is found. When one is not found, the user to switch to can be the owner of the default/ subdirectory, for example -- I don't really care for this case. >>> however, the process that >>> handles the actual connection from the client is running with reduced >>> privileges. so, there is a security benefit. >>> >> It will drop the root-privileges under my proposal as well. It is just >> that the new UID will be that of the connecting user as determined by >> the BD_ADDR match, if such a match can be found. Otherwise, yes, it >> should become whatever user is specified with the -u switch. >> > if you are arguing that having separate 'obex' user provides no > security benefits, then i disagree. and here is why. > > to me security is about managing the risks. i have to assume that > someone will break into someone's system using obexapp as attack > vector. so, lets see what happens in this case > > (1) when obexapp is running as separate user 'obex' in chroot()ed > environment, the question is: what kind of damage 'obex' user can do > in chroot()ed environment? > > (2) when obexapp is running as potentially _any_ user in the system in > _unrestricted_ environment, the question is: what kind of damage _any_ > user can do while roaming free? > I have already conceded in the previous e-mail(s), that I agree, that chroot-ing into the found subdirectory is a good idea. So, it would not "unrestricted" environment. The damage will be limited to the attacker's full access to the user's designated subdirectory. And it will be exactly the same as in your approach, because -- under your approach -- all of the files in the designated subdirectory will be obex-owned and thus accessible to an obex' process. >> The only thing I do feel strongly about, is that, when a matching >> directory entry is found, the server shall perform a setuid not to the >> generic 'obex' user, but to the owner of that entry (and chroot into it, >> yes). >> > > like i said, its security vs. usability. i probably can live with > chroot()ing and changing uid to owner of the directory (and _not_ > symlink). > This is wrong. Consider: wallaby@tasmania (11) mkdir ~/bluetooth wallaby@tasmania (12) echo 'Please, map my ~wallaby/bluetooth to my device' | write root ... root@tasmania (713) ln -s ~wallaby/bluetooth /var/spool/obex/Wallaby-Blackerry root@tasmania (714) echo 'Done, enjoy!' | write wallaby ... wallaby@tasmania (13) rmdir ~/bluetooth wallaby@tasmania (14) ln -s ~wombat/bluetooth ~/bluetooh Voila, because you trust stat(2) instead of lstat(2), Wallaby has just gained full access to Wombat's bluetooth files -- and can switch to anyone else's at will... When you use lstat, you make it root's responsibility to chown the BD_ADDR-symlinks under /var/spool/obex appropriately. Root may screw it up (and you may want to reject connections, if a particular entry belongs to root), but using stat(2) you give them no chance... > broken symlinks is a bad idea, imo. i still do not get what do you > gain by changing ownership on files in the same directory. perhaps i'm > missing something here. please give me an example. > Therein lies the problem -- the "broken symlinks" are a very useful thing, but suffer from the negative connotations of the word "broken". There is nothing wrong with them -- and /etc/make.conf provides a great example. They are very convenient in that they can be read and written in a single transaction (readlink(2) and symlink(2)) -- instead of open(2), read(2)/write(2), close(2). Their content is immediately readable with ls, and a directory containing them can also be modified atomically (even from scripts: with readlink(1), rm, ln) without locking. That's why "broken symlinks" aren't bad in general... Now, back to the topic at hand, my plan would've been an improvement over the current situation. Whereas the existing obexapp (and the new one, because you insist on the new behavior being optional) would dump everything into the same directory under the same ownership, my approach would allow different files to belong to different users, even if they still share the same directory. For example, a group of photographers dropping off pictures into the common area may want to use the same server-directory. But they would still prefer to be able to distinguish, who made which picture. That said, under my approach such multi-user sharing is still possible, even if you insist on BD_ADDR-entries being directories: root@tasmania (817) mkdir /home/dropoff root@tasmania (818) chmod 1777 /home/dropoff root@tasmania (819) foreach cam (Wallaby Wombat Pademelon Thylacine) foreach? ln -s /home/dropoff /var/spool/$cam-Camera foreach? chown -h $cam /var/spool/$cam-Camera foreach? end Under my proposal, the dropped-off pictures will belong to the proper users, while all residing in the same directory (for the editors to view). Under your proposal, such sharing would be far more involved to set up for no extra security... So, the only thing I insist on, is that lstat be used to determine the UID to switch to (after chroot-ing), when a matching BD_ADDR (or bt_hostname) is found. > like i said, its probably ok to change uid to owner of the _directory_ > and chroot() into it. but lstat(2) is out, sorry :) > Please, consider the above security example. stat is insecure for our purpose, while lstat is just fine. -mi From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 17:58:29 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABE88106564A for ; Tue, 14 Apr 2009 17:58:29 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by mx1.freebsd.org (Postfix) with ESMTP id 83B1F8FC13 for ; Tue, 14 Apr 2009 17:58:29 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 9592 invoked from network); 14 Apr 2009 17:58:28 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 17:58:28 -0000 Message-ID: <49E4CEC2.6060505@aldan.algebra.com> Date: Tue, 14 Apr 2009 13:58:26 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Iain Hibbert References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <1239725723.321671.1132.nullmailer@galant.ukfsn.org> In-Reply-To: <1239725723.321671.1132.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:58:30 -0000 Iain Hibbert ΞΑΠΙΣΑΧ(ΜΑ): > I agree too, its not good to run a daemon (that can be accessed over a > radio link and create/modify files no less) as root. > Both proposals being discussed currently presume the original daemon running as root, dropping privileges only after forking. Whatever mechanism is devised to avoid that, would be applicable to both, so lets put this part "outside of the parentheses" :-) > If you did that, it would I think be better to have the bdaddr mapping in > a config file. Symlinks are too much trouble. On the other hand, I'm not > keen on config files either :) > Config-files are a far greater "evil". Their maintenance by more than one person (or one with more than one terminal) requires locking, etc. -- for no additional benefit. Just use `ls -l' instead of `cat'... Symlinks (be they "broken" or not) can be maintained atomically and are thus superior. And each record keeps the timestamp and other useful info... >> But what about dropping camera's pictures and videos? People would certainly expect to be able to do that straight from their devices (rather than by running a client of some sort), and find the files somewhere under their home directories (perhaps in ~/Desktop). >> > > Do you want to send pictures to your account when your wife is logged in, > or does she want to when you are logged in? I don't see, how this is relevant. Everything, I and Maksim, are talking about is equally applicable even to a completely headless server. In my earlier e-mail (responding to Maksim), I give an example of a server set up to accept media uploads from multiple photographers (think of the guys with giant lenses around a football field, wirelessly pushing their snaps to the single box, from which editors pick them up for broadcasting/publishing nearly real-time) -- nobody needs to be logged-in to the box itself for that to work... > I don't know what prior art is there, but it seems to me that (as I said before) the person logged in at the console owns the machine and should receive files being sent. I don't know, what you mean. The two of us (and the babysitter, BTW) each have our own X-session, which are all started by KDM on demand. Ctrl-Alt-F9 is, usually, me, Ctrl-Alt-F10 -- the better third, and Ctrl-Alt-F11 -- whoever else needs access to their e-mail... None of this is relevant, though, I think... > For this reason, Bluetooth cannot properly be a multi-user link unless all the users trust each other (while Alice is sending files to the computer, Bill could be checking her phone log) so I don't see a problem with having all the files in a master directory owned by the same user (but setting the default path per remote device seems a good compromise) > Yes, it is a good compromise. And it can go one step further towards convenience (without compromising security), by using not just the device-specific PATH, but also the device-specific UID/GID... Yours, -mi From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 18:55:06 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A904106564A for ; Tue, 14 Apr 2009 18:55:06 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id C1E678FC0C for ; Tue, 14 Apr 2009 18:55:05 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1605265yxm.13 for ; Tue, 14 Apr 2009 11:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MLxrt8+v9Kpj42vbuM/fjGgRuY2O/sbTMMAZewQlsXQ=; b=vzV/6X4IBd23T1pHx/n3daduz5OGwjSaJJkpxwqR8vNWSHLzKYQnXt/ZP378ysV1lT QvqNg5qhlfENZEkIJR9uW/lIP++FRfCL5IwG8a047T0TZaFRIQdtFSL82oE6b1Kn7Wp+ obuQ9wgIAnOprJh+u1r5hpbw7WF4SXKRKU25c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LgnRXhECduurFKO1xCpYWV01SXzLgqpR1OW3xMiJKINBdr5U+f3DDEzfE9PeOuWKJ8 bcWQe3fxvtsiIiTpvOIHJ+9aFpaGHTmB5st6/mZInhJxwB7e71xpPZxuiCKXIY71wY8T mPNVv8qJzxLujnN4HZu2Pn2z2BW/cco7hCHrY= MIME-Version: 1.0 Received: by 10.90.119.20 with SMTP id r20mr8136183agc.8.1239735304981; Tue, 14 Apr 2009 11:55:04 -0700 (PDT) In-Reply-To: <49E4CAE1.6090506@aldan.algebra.com> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <49E4CAE1.6090506@aldan.algebra.com> Date: Tue, 14 Apr 2009 11:55:04 -0700 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 18:55:06 -0000 2009/4/14 Mikhail T. : > Maksim Yevmenkin =CE=C1=D0=C9=D3=C1=D7(=CC=C1): >> 2009/4/13 Mikhail T. : >> >> not really, as i said in my original email user's private obex >> directory is owned by 'obex' user, but the group is still set to the >> user's group and permissions are set to 0770. > > Even if the GID of the files will be that of the user, it being owned by > obex will cause inconvenience. something's gotta give :) can't please everybody :) [...] >>>> however, the process that >>>> handles the actual connection from the client is running with reduced >>>> privileges. so, there is a security benefit. >>>> >>> It will drop the root-privileges under my proposal as well. It is just >>> that the new UID will be that of the connecting user as determined by >>> the BD_ADDR match, if such a match can be found. Otherwise, yes, it >>> should become whatever user is specified with the -u switch. >>> >> if you are arguing that having separate 'obex' user provides no >> security benefits, then i disagree. and here is why. >> >> to me security is about managing the risks. i have to assume that >> someone will break into someone's system using obexapp as attack >> vector. so, lets see what happens in this case >> >> (1) when obexapp is running as separate user 'obex' in chroot()ed >> environment, the question is: what kind of damage 'obex' user can do >> in chroot()ed environment? >> >> (2) when obexapp is running as potentially _any_ user in the system in >> _unrestricted_ environment, the question is: what kind of damage _any_ >> user can do while roaming free? >> > I have already conceded in the previous e-mail(s), that I agree, that > chroot-ing into the found subdirectory is a good idea. So, it would not > "unrestricted" environment. The damage will be limited to the attacker's > full access to the user's designated subdirectory. And it will be > exactly the same as in your approach, because -- under your approach -- > all of the files in the designated subdirectory will be obex-owned and > thus accessible to an obex' process. ah, not exactly. its not only the files that 'bad guy' can upload into (possibly chroot()ed) environment. its the user id. for example, what if certain user id has access to a certain device node? 'bad guy' could just mknod(8) device node and ... >>> The only thing I do feel strongly about, is that, when a matching >>> directory entry is found, the server shall perform a setuid not to the >>> generic 'obex' user, but to the owner of that entry (and chroot into it= , >>> yes). >> >> like i said, its security vs. usability. i probably can live with >> chroot()ing and changing uid to owner of the directory (and _not_ >> symlink). >> > This is wrong. Consider: > > wallaby@tasmania (11) mkdir ~/bluetooth > wallaby@tasmania (12) echo 'Please, map my ~wallaby/bluetooth to my > device' | write root > ... > root@tasmania (713) ln -s ~wallaby/bluetooth > /var/spool/obex/Wallaby-Blackerry > root@tasmania (714) echo 'Done, enjoy!' | write wallaby > ... > wallaby@tasmania (13) rmdir ~/bluetooth > wallaby@tasmania (14) ln -s ~wombat/bluetooth ~/bluetooh > > Voila, because you trust stat(2) instead of lstat(2), Wallaby has just > gained full access to Wombat's bluetooth files -- and can switch to > anyone else's at will... hmm.... perhaps, i'm missing something here. here is what i did =3D=3D step 1 =3D=3D %id uid=3D1004(wallaby) gid=3D1004(wallaby) groups=3D1004(wallaby) %mkdir ~/bluetooth %ls -l drwxr-xr-x 2 wallaby wallaby 512 Apr 14 11:20 bluetooth =3D=3D step 2 =3D=3D beetle# pwd /var/spool/obex beetle# ln -s ~wallaby/bluetooth Wallaby-Blackerry beetle# ls -l lrwxr-xr-x 1 root obex 23 Apr 14 11:21 Wallaby-Blackerry -> /home/wallaby/bluetooth beetle# stat -L Wallaby-Blackerry 99 1490343 drwxr-xr-x 2 wallaby wallaby 5953437 512 "Apr 14 11:20:37 2009" "Apr 14 11:20:37 2009" "Apr 14 11:20:37 2009" "Apr 14 11:20:37 2009" 4096 4 0 Wallaby-Blackerry so as you can see user/group ids are correct, i.e. wallaby/wallaby =3D=3D step 3 =3D=3D %id uid=3D1005(wombat) gid=3D1005(wombat) groups=3D1005(wombat) %mkdir ~/bluetooth %ls -l drwxr-xr-x 2 wombat wombat 512 Apr 14 11:22 bluetooth =3D=3D step 4 =3D=3D %id uid=3D1004(wallaby) gid=3D1004(wallaby) groups=3D1004(wallaby) %pwd /usr/home/wallaby %rmdir bluetooth/ %ln -s ~wombat/bluetooth ~/bluetooth %ls -l lrwxr-xr-x 1 wallaby wallaby 22 Apr 14 11:29 bluetooth -> /home/wombat/bluetooth =3D=3D step 5 =3D=3D beetle# pwd /var/spool/obex beetle# stat -L Wallaby-Blackerry 99 1490434 drwxr-xr-x 2 wombat wombat 5953822 512 "Apr 14 11:22:10 2009" "Apr 14 11:22:10 2009" "Apr 14 11:22:10 2009" "Apr 14 11:22:10 2009" 4096 4 0 Wallaby-Blackerry so, as you can see user/group ids are still correct, i.e. wombat/wombat. also i used stat -L which makes use of stat(2) instead of lstat(2). so from what i can see, and please feel free to correct me if i wrong, user wallaby just intentionally 'gave up' his/her files to user 'wombat'. i do not see any problem here, do you? or am i missing something obvious here? > When you use lstat, you make it root's responsibility to chown the > BD_ADDR-symlinks under /var/spool/obex appropriately. Root may screw it > up (and you may want to reject connections, if a particular entry > belongs to root), but using stat(2) you give them no chance... if 'root' screws up, then game is over :) period. you can make this argument with any piece of software out there :) >> broken symlinks is a bad idea, imo. i still do not get what do you >> gain by changing ownership on files in the same directory. perhaps i'm >> missing something here. please give me an example. >> > Therein lies the problem -- the "broken symlinks" are a very useful > thing, but suffer from the negative connotations of the word "broken". > There is nothing wrong with them -- and /etc/make.conf provides a great > example. They are very convenient in that they can be read and written please let it go already :) i heard your point about /etc/malloc.conf several times. you made it loud and clear. just because someone did it this way, does not mean the the same model should be applied for everything else. i'm sure whoever did this had good reasons for doing it this way. keep in mind that someone else (or possibly the same person) provided MALLOC_OPTIONS environmental variable and _malloc_options global variable to override /etc/malloc.conf. imo, its fine to use 'broken' symlinks to pass a few characters, however, you suggesting to use the same model for something that is more complicated. there probably are people who are confused about permission on symlink vs. permissions on the directory symlink points to. i was one of those people in not too distant past :-) > in a single transaction (readlink(2) and symlink(2)) -- instead of > open(2), read(2)/write(2), close(2). Their content is immediately > readable with ls, and a directory containing them can also be modified > atomically (even from scripts: with readlink(1), rm, ln) without > locking. That's why "broken symlinks" aren't bad in general... ok, 'broken' symlinks are bad idea, imo, when used as access control mechanism :) > Now, back to the topic at hand, my plan would've been an improvement > over the current situation. Whereas the existing obexapp (and the new > one, because you insist on the new behavior being optional) would dump > everything into the same directory under the same ownership, my approach > would allow different files to belong to different users, even if they > still share the same directory. > > For example, a group of photographers dropping off pictures into the > common area may want to use the same server-directory. But they would > still prefer to be able to distinguish, who made which picture. bad example - meta data in the pictures themselves tell much better story := ) > That said, under my approach such multi-user sharing is still possible, > even if you insist on BD_ADDR-entries being directories: > > root@tasmania (817) mkdir /home/dropoff > root@tasmania (818) chmod 1777 /home/dropoff > root@tasmania (819) foreach cam (Wallaby Wombat Pademelon Thylacine) > foreach? ln -s /home/dropoff /var/spool/$cam-Camera > foreach? chown -h $cam /var/spool/$cam-Camera > foreach? end > > Under my proposal, the dropped-off pictures will belong to the proper > users, while all residing in the same directory (for the editors to > view). Under your proposal, such sharing would be far more involved to > set up for no extra security... again, bad example, imo. all pictures will end up in /home/dropoff owned by the same user (either 'obex' or owner of '/home/dropoff'). just point editors to /home/dropoff instead of /var/spool/obex and be done with it. the only difference is that all the files will be owned by the same user, but like i said, meta data in the pictures will tell far better story then user id :) i also do not understand why 'sticky bit' is required (its only needed in your version of the patch). > So, the only thing I insist on, is that lstat be used to determine the > UID to switch to (after chroot-ing), when a matching BD_ADDR (or > bt_hostname) is found. please see my example above. >> like i said, its probably ok to change uid to owner of the _directory_ >> and chroot() into it. but lstat(2) is out, sorry :) >> > Please, consider the above security example. stat is insecure for our > purpose, while lstat is just fine. hmm, for my example above beetle# stat Wallaby-Blackerry 98 47348 lrwxr-xr-x 1 root obex 1836017711 23 "Apr 14 11:21:23 2009" "Apr 14 11:21:23 2009" "Apr 14 11:21:23 2009" "Apr 14 11:21:23 2009" 4096 0 0 Wallaby-Blackerry and (with trailing /) beetle# stat Wallaby-Blackerry/ 99 1490343 lrwxr-xr-x 1 wallaby wallaby 1836017711 22 "Apr 14 11:29:08 2009" "Apr 14 11:29:08 2009" "Apr 14 11:29:08 2009" "Apr 14 11:29:08 2009" 4096 0 0 Wallaby-Blackerry/ stat(1) _without_ '-L' option uses lstat(2). thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 19:55:04 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B571065673 for ; Tue, 14 Apr 2009 19:55:04 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id D94ED8FC17 for ; Tue, 14 Apr 2009 19:55:03 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 32297 invoked from network); 14 Apr 2009 19:55:03 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 19:55:02 -0000 Message-ID: <49E4EA14.80300@aldan.algebra.com> Date: Tue, 14 Apr 2009 15:55:00 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Maksim Yevmenkin References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <49E4CAE1.6090506@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 19:55:04 -0000 Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): > something's gotta give :) can't please everybody :) > You can make sure, the uploaded files belong to the owner of the device, that uploaded them. >> I have already conceded in the previous e-mail(s), that I agree, that >> chroot-ing into the found subdirectory is a good idea. So, it would not >> "unrestricted" environment. The damage will be limited to the attacker's >> full access to the user's designated subdirectory. And it will be >> exactly the same as in your approach, because -- under your approach -- >> all of the files in the designated subdirectory will be obex-owned and >> thus accessible to an obex' process. >> > > ah, not exactly. its not only the files that 'bad guy' can upload into > (possibly chroot()ed) environment. its the user id. for example, what > if certain user id has access to a certain device node? 'bad guy' > could just mknod(8) device node and ... > First of all, mknod(8) utility is deprecated on modern FreeBSD systems -- in favor of devfs. So, you are worried, that a bad guy will impersonate wallaby and access a wallaby-owned device? I don't think, this is possible in default FreeBSD installations. And admins granting some users direct access to devices may chose to limit remote access to these user accounts. > beetle# stat -L Wallaby-Blackerry > 99 1490434 drwxr-xr-x 2 wombat wombat 5953822 512 "Apr 14 11:22:10 > 2009" "Apr 14 11:22:10 2009" "Apr 14 11:22:10 2009" "Apr 14 11:22:10 > 2009" 4096 4 0 Wallaby-Blackerry > > so, as you can see user/group ids are still correct, i.e. wombat/wombat. > Wombat UID for Wallaby-Blackberry is NOT correct! > also i used stat -L which makes use of stat(2) instead of lstat(2). so > from what i can see, and please feel free to correct me if i wrong, > user wallaby just intentionally 'gave up' his/her files to user > 'wombat'. i do not see any problem here, do you? or am i missing > something obvious here? > Yes, exactly as above! User of Wallaby-Blackberry will connect and -- depending on their own choice -- have full access to Wombat's files, because stat will tell obexapp, to use UID of wombat, whereas lstat would've told it to use the UID of Wallaby (and fail to access Wombat's 600-moded files). In fact, because Wallaby is free to make their own ~/bluetooth a symlink to ANYTHING, they may get access to ANYBODY's files, even those of users, who don't use Bluetooth. Once root sets up /var/spool/obex/Wallaby-Blackberry pointing at /home/wallaby/bluetooth, user Wallaby can change that link to anything -- except, perhaps, root themselves... >> When you use lstat, you make it root's responsibility to chown the >> BD_ADDR-symlinks under /var/spool/obex appropriately. Root may screw it >> up (and you may want to reject connections, if a particular entry >> belongs to root), but using stat(2) you give them no chance... >> > if 'root' screws up, then game is over :) period. you can make this argument with any piece of software out there :) > I agree. Which is why I keep saying, you should be using lstat (to read info on entries created by root under /var/spool/obex), instead of stat (which would give you info on entries maintained by the -- potentially malicious -- users). > there probably are people who are confused about > permission on symlink vs. permissions on the directory symlink points > to. i was one of those people in not too distant past :-) > Didn't we just agree, that root being confused is a "game-over" and shall not be mentioned? >> That's why "broken symlinks" aren't bad in general... >> > ok, 'broken' symlinks are bad idea, imo, when used as access control > mechanism :) > Slow, painful, but still progress... :-) >> For example, a group of photographers dropping off pictures into the >> common area may want to use the same server-directory. But they would >> still prefer to be able to distinguish, who made which picture. >> > > bad example - meta data in the pictures themselves tell much better story :) > You are nit-picking, but no, actually. The EXIF metadata (BTW, relying on file-format specific metadata to provide information, that filesystem itself can/should provide, seems wrong in itsefl) will give the camera's model and the time of the shot, but not the owner... It does not matter, again, because multiple BD_ADDR symlinks can still point to the same directory. >> That said, under my approach such multi-user sharing is still possible, >> even if you insist on BD_ADDR-entries being directories: >> >> root@tasmania (817) mkdir /home/dropoff >> root@tasmania (818) chmod 1777 /home/dropoff >> root@tasmania (819) foreach cam (Wallaby Wombat Pademelon Thylacine) >> foreach? ln -s /home/dropoff /var/spool/$cam-Camera >> foreach? chown -h $cam /var/spool/$cam-Camera >> foreach? end >> >> Under my proposal, the dropped-off pictures will belong to the proper >> users, while all residing in the same directory (for the editors to >> view). Under your proposal, such sharing would be far more involved to >> set up for no extra security... >> > > again, bad example, imo. all pictures will end up in /home/dropoff > owned by the same user (either 'obex' or owner of '/home/dropoff'). > They will under YOUR proposal (using stat). Under mine (using lstat), the files will have different owning UIDs... Which is good :-) You may not like a particular example, but you have to admit, that my proposal gives more flexibility to the admin setting up BT-access. They can, if they want to, allow meaningful directory-sharing for the files belonging to different users. And if they don't want to, they can keep all symlinks pointing to /home/dropoff belong to `obex' (or whoever). Under your proposal, there is no such flexibility and yet it is not any more secure (sorry, mknod is too superficial). Escaping from chroot is never easy, and for non-root users it is impossible -- without bugs in the kernel... > just point editors to /home/dropoff instead of /var/spool/obex and be done with it. Of course, the editors would be looking at /home/dropoff! I don't even understand, how what I wrote could've been read differently. The editors will be looking at /home/dropoff (or, more likely, something like \\dropoff\dropoff\). And in there they will be able to group files by users (owners of the matching entries under /var/spool/obex) -- if you take my approach (lstat). Under your approach (stat), the user would be the same (owner of /home/dropoff)... > i also do not understand why 'sticky bit' is required (its only needed in your version of the patch). > It is not required -- only to prevent people from (accidentally, perhaps) overwriting each other's files under certain circumstances. To summarize, you seem willing to consider the owner of the matching entry when determining, which UID to switch to when dropping root-privileges after chroot. The only remaining disagreement is whether to use lstat vs. stat for the purpose. It being, literally, a one-character change in the code, you can go ahead and begin coding the change to match your style preferences. In the mean time, consider the example I just gave, showing stat being a security hole... Yours, -mi From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 21:38:34 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8586E106564A for ; Tue, 14 Apr 2009 21:38:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 24A3A8FC19 for ; Tue, 14 Apr 2009 21:38:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1654290ywh.13 for ; Tue, 14 Apr 2009 14:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2lc1FL4O67WIkWrYBa2npwSMB63B3sLX0EIN1I31NyM=; b=WKwIGJ0zFWxgCTZfSFPX+EwbbpUn37qhXcFCPT4uwfg0WckTHya53PNF9wShD/Prhb 46i/k3cswx+WFwrv+uLAEr8v7/LC2SGqm4eRRHfxCki0SUSCo2FvGZfJp0S6mSBm0qnG /K4RXb+XnwAlanFNU/AKdRZmJLaUyg/pD4dJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j/9p7/qfmcmeKRmDApTptpUDCI/Xzw1UP+vC5STHLZ045+s7wFq1BBq+6fxHDmgRgZ bGPWVPmRyYbRajXE8jKjAna4Y/LMwIfYooxa0xnmJhUwNhULqIa59n0axJ5KnSGNMJ2e 6EKmhwNGadSSiyoz8X5H8dm0yJxQchG4ee3eE= MIME-Version: 1.0 Received: by 10.90.97.18 with SMTP id u18mr10343912agb.55.1239745113520; Tue, 14 Apr 2009 14:38:33 -0700 (PDT) In-Reply-To: <49E4EA14.80300@aldan.algebra.com> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <49E4CAE1.6090506@aldan.algebra.com> <49E4EA14.80300@aldan.algebra.com> Date: Tue, 14 Apr 2009 14:38:33 -0700 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: multipart/mixed; boundary=0016361e7db21a795504678aa701 Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 21:38:35 -0000 --0016361e7db21a795504678aa701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/4/14 Mikhail T. : [...] > Slow, painful, but still progress... :-) please find attached revised patch that implements mi's (aka Mikhail) initial suggestion, i.e. use lstat(2) instead of stat(2). i've also changed it a bit to allow both cases, i.e. (1) when virtual root folder is requested and -u option is set, obexapp will always run as ; (2) when virtual root folder is requested and _no_ -u option was specified, obexapp will run as the owner of the found virtual root folder entry (where entry is either symlink or actual subdirectory under default root folder); i've also included a patch, submitted by Ronald Klop to disable spinner in client mode for non-interactive client sessions. [...] > To summarize, you seem willing to consider the owner of the matching > entry when determining, which UID to switch to when dropping > root-privileges after chroot. The only remaining disagreement is whether > to use lstat vs. stat for the purpose. It being, literally, a > one-character change in the code, you can go ahead and begin coding the > change to match your style preferences. > > In the mean time, consider the example I just gave, showing stat being a > security hole... yes, now i get it :) sorry for being such a bonehead :) hopefully the latest patch will work for everyone. thanks, max --0016361e7db21a795504678aa701 Content-Type: text/plain; charset=US-ASCII; name="obexapp-uid4.diff.txt" Content-Disposition: attachment; filename="obexapp-uid4.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ftj3uk8i0 SW5kZXg6IGV2ZW50LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Vzci9sb2NhbC9jdnMvcG9ydHMv b2JleGFwcC9ldmVudC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjYKZGlmZiAtdSAtcjEuNiBl dmVudC5jCi0tLSBldmVudC5jCTUgSmFuIDIwMDkgMTY6Mzc6MjUgLTAwMDAJMS42CisrKyBldmVu dC5jCTE0IEFwciAyMDA5IDIxOjIzOjE2IC0wMDAwCkBAIC0xLDcgKzEsNyBAQAogLyoKICAqIGV2 ZW50LmMKICAqCi0gKiBDb3B5cmlnaHQgKGMpIDIwMDIgTWFrc2ltIFlldm1lbmtpbiA8bV9ldm1l bmtpbkB5YWhvby5jb20+CisgKiBDb3B5cmlnaHQgKGMpIDIwMDItMjAwOSBNYWtzaW0gWWV2bWVu a2luIDxtX2V2bWVua2luQHlhaG9vLmNvbT4KICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCiAgKgog ICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0 aCBvciB3aXRob3V0CkBAIC0zMiw2ICszMiw3IEBACiAjaW5jbHVkZSA8Ymx1ZXRvb3RoLmg+CiAj aW5jbHVkZSA8b2JleC5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVkZSA8dW5pc3RkLmg+ CiAKICNpbmNsdWRlICJjb21wYXQuaCIKICNpbmNsdWRlICJvYmV4YXBwLmgiCkBAIC0xMzEsNyAr MTMyLDcgQEAKIAogCWxvZ19kZWJ1ZygiJXMoKTogTWFkZSBzb21lIHByb2dyZXNzLi4uIiwgX19m dW5jX18pOwogCi0JaWYgKCFjb250ZXh0LT5zZXJ2ZXIpIHsKKwlpZiAoIWNvbnRleHQtPnNlcnZl ciAmJiAhY29udGV4dC0+bmkgJiYgaXNhdHR5KFNURE9VVF9GSUxFTk8pKSB7CiAJCXN0YXRpYyBj aGFyCXNwaW5uZXJbXSA9ICJcXHwvLSI7CiAJCXN0YXRpYyB1aW50MzJfdAlzcGlubmVyX2lkeCA9 IDA7CiAKSW5kZXg6IG1haW4uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvdXNyL2xvY2FsL2N2cy9w b3J0cy9vYmV4YXBwL21haW4uYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMwpkaWZmIC11IC1y MS4xMyBtYWluLmMKLS0tIG1haW4uYwkyMyBBcHIgMjAwNyAxODoyOToxOCAtMDAwMAkxLjEzCisr KyBtYWluLmMJMTQgQXByIDIwMDkgMjE6MjM6MzggLTAwMDAKQEAgLTEsNyArMSw3IEBACiAvKgog ICogbWFpbi5jCiAgKgotICogQ29weXJpZ2h0IChjKSAyMDAyIE1ha3NpbSBZZXZtZW5raW4gPG1f ZXZtZW5raW5AeWFob28uY29tPgorICogQ29weXJpZ2h0IChjKSAyMDAyLTIwMDkgTWFrc2ltIFll dm1lbmtpbiA8bV9ldm1lbmtpbkB5YWhvby5jb20+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgog ICoKICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMs IHdpdGggb3Igd2l0aG91dApAQCAtNjUsNyArNjUsNyBAQAogewogCXN0cnVjdCBzaWdhY3Rpb24J c2E7CiAJY2hhcgkJCSplcCA9IE5VTEwsICpwcmlfbmFtZSA9IE5VTEw7Ci0JaW50CQkJbiwgc2Vy dmljZSwgbm9uaW50ZXJhY3RpdmU7CisJaW50CQkJbiwgc2VydmljZSwgZGV0YWNoOwogCWNvbnRl eHRfdAkJY29udGV4dDsKIAlvYmV4X2N0cmFuc190CQljdXN0ZnVuYzsKIApAQCAtODMsNyArODMs NyBAQAogCS8qIFByZXBhcmUgY29udGV4dCAqLwogCW1lbXNldCgmY29udGV4dCwgMCwgc2l6ZW9m KGNvbnRleHQpKTsKIAljb250ZXh0LnRmZCA9IGNvbnRleHQuc2ZkID0gLTE7Ci0JY29udGV4dC5k ZXRhY2ggPSAxOworCWRldGFjaCA9IDE7CiAKIAljb250ZXh0LmxzX3NpemUgPSBPQkVYQVBQX0JV RkZFUl9TSVpFOwogCWlmICgoY29udGV4dC5scyA9IChjaGFyICopIG1hbGxvYyhjb250ZXh0Lmxz X3NpemUpKSA9PSBOVUxMKQpAQCAtMTE4LDggKzExOCw4IEBACiAJY3VzdGZ1bmMuY3VzdG9tZGF0 YSA9ICZjb250ZXh0OwogCiAJLyogUHJvY2VzcyBjb21tYW5kIGxpbmUgb3B0aW9ucyAqLwotCXNl cnZpY2UgPSBub25pbnRlcmFjdGl2ZSA9IDA7Ci0Jd2hpbGUgKChuID0gZ2V0b3B0KGFyZ2MsIGFy Z3YsICJhOkE6Y0M6ZERmaGw6bTpucjpTc3U6IikpICE9IC0xKSB7CisJc2VydmljZSA9IDA7CisJ d2hpbGUgKChuID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJhOkE6Y0M6ZERmaGw6bTpucjpSc1N1OiIp KSAhPSAtMSkgewogCQlzd2l0Y2ggKG4pIHsKIAkJY2FzZSAnYSc6CiAJCQlpZiAoIWJ0X2F0b24o b3B0YXJnLCAmY29udGV4dC5yYWRkcikpIHsKQEAgLTE4MCw3ICsxODAsNyBAQAogCQkJYnJlYWs7 CiAKIAkJY2FzZSAnZCc6IC8qIGRvIG5vdCBkZXRhY2ggc2VydmVyICovCi0JCQljb250ZXh0LmRl dGFjaCA9IDA7CisJCQlkZXRhY2ggPSAwOwogCQkJYnJlYWs7CiAKIAkJY2FzZSAnRCc6IC8qIHVz ZSBzdGRpbi9zdGRvdXQgKi8KQEAgLTIwOSw3ICsyMDksNyBAQAogCQkJCXVzYWdlKGJhc2VuYW1l KGFyZ3ZbMF0pKTsKIAkJCQkvKiBOT1QgUkVBQ0hFRCAqLwogCi0JCQlub25pbnRlcmFjdGl2ZSA9 IDE7CisJCQljb250ZXh0Lm5pID0gMTsKIAkJCWJyZWFrOwogCiAJCWNhc2UgJ3InOiAvKiByb290 ICovCkBAIC0yMTcsOCArMjE3LDEzIEBACiAJCQkJZXJyKDEsICJDb3VsZCBub3QgcmVhbHBhdGgo JXMpIiwgb3B0YXJnKTsKIAkJCWJyZWFrOwogCisJCWNhc2UgJ1InOiAvKiB2aXJ0dWFsaXplIHJv b3QgZm9yIGVhY2ggZGV2aWNlICovCisJCQljb250ZXh0LnZyb290ID0gMTsKKwkJCWNvbnRleHQu c2VjdXJlID0gMTsKKwkJCWJyZWFrOworCiAJCWNhc2UgJ3MnOiAvKiBzZXJ2ZXIgKi8KLQkJCWlm IChub25pbnRlcmFjdGl2ZSkKKwkJCWlmIChjb250ZXh0Lm5pKQogCQkJCXVzYWdlKGJhc2VuYW1l KGFyZ3ZbMF0pKTsKIAkJCQkvKiBOT1QgUkVBQ0hFRCAqLwogCkBAIC0yNjksMjMgKzI3NCwxMCBA QAogCWxvZ19vcGVuKCJvYmV4YXBwIiwgcHJpX25hbWUsIDApOwogCiAJLyogRGV0YWNoIHNlcnZl ciAoaWYgcmVxdWlyZWQpICovCi0JaWYgKGNvbnRleHQuc2VydmVyICYmIGNvbnRleHQuZGV0YWNo KSB7Ci0JCXBpZF90CXBpZCA9IGZvcmsoKTsKLQotCQlpZiAocGlkID09IChwaWRfdCkgLTEpIHsK LQkJCWxvZ19lcnIoIiVzKCk6IENvdWxkIG5vdCBmb3JrLiAlcyAoJWQpIiwKLQkJCQlfX2Z1bmNf Xywgc3RyZXJyb3IoZXJybm8pLCBlcnJubyk7Ci0JCQlleGl0KDEpOwotCQl9Ci0KLQkJaWYgKHBp ZCAhPSAwKQotCQkJZXhpdCgwKTsKLQotCQlpZiAoZGFlbW9uKDAsIDApIDwgMCkgewotCQkJbG9n X2VycigiJXMoKTogQ291bGQgbm90IGRhZW1vbi4gJXMgKCVkKSIsCi0JCQkJX19mdW5jX18sIHN0 cmVycm9yKGVycm5vKSwgZXJybm8pOwotCQkJZXhpdCgxKTsKLQkJfQorCWlmIChjb250ZXh0LnNl cnZlciAmJiBkZXRhY2ggJiYgZGFlbW9uKDAsIDApIDwgMCkgeworCQlsb2dfZXJyKCIlcygpOiBD b3VsZCBub3QgZGFlbW9uLiAlcyAoJWQpIiwKKwkJCV9fZnVuY19fLCBzdHJlcnJvcihlcnJubyks IGVycm5vKTsKKwkJZXhpdCgxKTsKIAl9CiAKIAkvKiBJbml0aWFsaXplIE9CRVggKi8KQEAgLTMw NSw3ICsyOTcsNyBAQAogCiAJaWYgKGNvbnRleHQuc2VydmVyKQogCQluID0gb2JleGFwcF9zZXJ2 ZXIoY29udGV4dC5oYW5kbGUpOwotCWVsc2UgaWYgKG5vbmludGVyYWN0aXZlKQorCWVsc2UgaWYg KGNvbnRleHQubmkpCiAJCW4gPSBvYmV4YXBwX25vbl9pbnRlcmFjdGl2ZV9jbGllbnQoY29udGV4 dC5oYW5kbGUsIGFyZ2MsIGFyZ3YpOwogCWVsc2UKIAkJbiA9IG9iZXhhcHBfY2xpZW50KGNvbnRl eHQuaGFuZGxlKTsKSW5kZXg6IG9iZXhhcHAuMQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvdXNyL2xv Y2FsL2N2cy9wb3J0cy9vYmV4YXBwL29iZXhhcHAuMSx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4x NQpkaWZmIC11IC1yMS4xNSBvYmV4YXBwLjEKLS0tIG9iZXhhcHAuMQkyMSBNYXkgMjAwNyAxNTo1 NTozNSAtMDAwMAkxLjE1CisrKyBvYmV4YXBwLjEJMTQgQXByIDIwMDkgMjE6MjQ6MDggLTAwMDAK QEAgLTEsNiArMSw2IEBACiAuXCIgb2JleGFwcC4xCiAuXCIKLS5cIiBDb3B5cmlnaHQgKGMpIDIw MDEtMjAwMyBNYWtzaW0gWWV2bWVua2luIDxtX2V2bWVua2luQHlhaG9vLmNvbT4KKy5cIiBDb3B5 cmlnaHQgKGMpIDIwMDEtMjAwOSBNYWtzaW0gWWV2bWVua2luIDxtX2V2bWVua2luQHlhaG9vLmNv bT4KIC5cIiBBbGwgcmlnaHRzIHJlc2VydmVkLgogLlwiCiAuXCIgUmVkaXN0cmlidXRpb24gYW5k IHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CkBAIC0yNyw3 ICsyNyw3IEBACiAuXCIgJElkOiBvYmV4YXBwLjEsdiAxLjE1IDIwMDcvMDUvMjEgMTU6NTU6MzUg bWF4IEV4cCAkCiAuXCIgJEZyZWVCU0QkCiAuXCIKLS5EZCBBcHJpbCAxMCwgMjAwNworLkRkIEFw cmlsIDE0LCAyMDA5CiAuRHQgT0JFWEFQUCAxCiAuT3MKIC5TaCBOQU1FCkBAIC01NCw3ICs1NCw3 IEBACiAuQXIgcGFyYW1ldGVycwogLk5tCiAuRmwgcwotLk9wIEZsIGREU2gKKy5PcCBGbCBkRFNS aAogLk9wIEZsIEEgQXIgQkRfQUREUgogLkZsIEMgQXIgY2hhbm5lbAogLk9wIEZsIG0gQXIgTVRV CkBAIC0xOTMsNiArMTkzLDEyIEBACiBEZWZhdWx0cyB0byB0aGUgbWF4aW11bSBzdXBwb3J0ZWQg dmFsdWUuCiAuSXQgRmwgbiAKIFdvcmsgaW4gdGhlIG5vbi1pbnRlcmFjdGl2ZSBjbGllbnQgbW9k ZS4KKy5JdCBGbCBSCitWaXJ0dWFsaXplIHJvb3QgZm9sZGVyIGZvciBlYWNoIGNsaWVudCBkZXZp Y2UgaW4gc2VydmVyIG1vZGUuCitXaWxsIGF1dG9tYXRpY2FsbHkgdHVybiBvbiBzZWN1cmUgbW9k ZSwgaS5lLgorLkZsIFMKK29wdGlvbi4KK1BsZWFzZSByZWFkIHNlY3Rpb24gYmVsb3cgZm9yIGEg Y29tcGxldGUgZGVzY3JpcHRpb24uCiAuSXQgRmwgciBBciBwYXRoCiBTcGVjaWZ5IHJvb3QgZm9s ZGVyLgogRGVmYXVsdCByb290IGZvbGRlciBpbiB0aGUgc2VydmVyIG1vZGUgaXMKQEAgLTIxNiw2 ICsyMjIsNTcgQEAKIFRoZSB2YWx1ZSBzcGVjaWZpZWQgbWF5IGJlIGVpdGhlciBhIHVzZXJuYW1l IG9yIGEgbnVtZXJpYyB1c2VyIGlkLgogVGhpcyBvbmx5IHdvcmtzIGlmIHNlcnZlciB3YXMgc3Rh cnRlZCBhcyByb290LgogLkVsCisuU2ggVklSVFVBTCBST09UIEZPTERFUlMKK1doZW4gYWNjZXB0 aW5nIGNvbm5lY3Rpb25zIGluIHNlcnZlciBtb2RlLCAKKy5ObQord2lsbCBhdHRlbXB0IHRvIGZp bmQgYW4gZW50cnkgdGhhdCB3b3VsZCBhY3QgYXMgYSB2aXJ0dWFsIHJvb3QKK2ZvbGRlciBmb3Ig dGhlIGNvbm5lY3RpbmcgZGV2aWNlLgorVmlydHVhbCByb290IGZvbGRlcnMgbXVzdCByZXNpZGUg dW5kZXIgZGVmYXVsdCByb290IGZvbGRlciB3aGljaCBpcyBzZXQKK3dpdGgKKy5GbCByCitvcHRp b24uCitUaGUgcnVsZXMgYXJlIGFzIGZvbGxvd3M6CisuQmwgLWVudW0gLW9mZnNldCBpbmRlbnQg LWNvbXBhY3QKKy5JdAorLk5tCit3aWxsIHRyeSB0byByZXNvbHZlIGNvbm5lY3RpbmcgZGV2aWNl J3MgQkRfQUREUiB1c2luZworLlhyIGJ0X2dldGhvc3RieWFkZHIgMworY2FsbCBhbmQgY2hlY2sg Zm9yIGFuIGVudHJ5IHRoYXQgbWF0Y2hlcyByZXNvbHZlZCBuYW1lIChpZiBhbnkpOworLkl0Cisu Tm0KK3dpbGwgY2hlY2sgZm9yIGFuIGVudHJ5IHRoYXQgbWF0Y2hlcyBjb25uZWN0aW5nIGRldmlj ZSdzIEJEX0FERFI7CisuSXQKKy5ObQord2lsbCBjaGVjayBmb3IgYW4gZW50cnksIG5hbWVkCisu RHEgZGVmYXVsdCA7CisuRWwKK0lmIG5vbmUgb2YgdGhlIGFib3ZlIG1hdGNoZXMsIHRoZW4gdGhl IGNvbm5lY3Rpb24gdG8gdGhlIGNsaWVudCBpcyB0ZXJtaW5hdGVkLgorT3RoZXJ3aXNlLAorLk5t Cit3aWxsIHRyeSB0byBjaGFuZ2UgZGVmYXVsdCByb290IGZvbGRlciB0aGUgdGhlIGZvdW5kIGVu dHJ5LgorLlBwCitJZgorLkZsIHUKK29wdGlvbiB3YXMgc3BlY2lmaWVkLCB0aGUKKy5ObQord2ls bCB0cnkgdG8gY2hhbmdlIHRvIHRoZSBzcGVjaWZpZWQgdXNlci4KK090aGVyd2lzZQorLk5tCit3 aWxsIHRyeSBjaGFuZ2UgdG8gdGhlIHVzZXIsIHRoYXQgb3ducyB0aGUgZm91bmQgZW50cnkuCitU aGF0IGlzLCBpZiB0aGUgZm91bmQgZW50cnkgaXMgYSBzeW1saW5rLCB0aGUKKy5ObQord2lsbCB0 cnkgY2hhbmdlIHRvIHRoZSB1c2VyLCB0aGF0IG93bnMgc3ltbGluayBhbmQgbm90IHRvIHRoZSB1 c2VyLCB0aGF0Citvd25zIHRoZSBlbnRyeSBzeW1saW5rIHBvaW50cyB0by4KKy5QcAorVGhpcyBh bGxvd3MgdGhlIHNhbWUgc3lzdGVtIHRvIGludGVsbGlnZW50bHkgZGlzdGluZ3Vpc2ggZGlmZmVy ZW50CitjbGllbnQgZGV2aWNlcyBhcyBiZWxvbmdpbmcgdG8gZGlmZmVyZW50IHVzZXJzLgorQW4g YWRtaW5pc3RyYXRvciBjYW4gc2V0IHVwIHRoZSBzdWJkaXJlY3RvcmllcyBmb3IKK2tub3duIGRl dmljZXMgdW5kZXIKKy5QYSAvdmFyL3Nwb29sL29iZXgKKyhvciB3aGVyZXZlciwgc2VlCisuRmwg cgorb3B0aW9uKSBmb3IgZWFjaCB1c2VyLCBvciBldmVuIGFzIHN5bWxpbmtzIHRvIGVhY2ggdXNl cidzIGhvbWUgZGlyZWN0b3J5Cisob3IgYSBzdWJkaXJlY3RvcnkgdGhlcmVvZikuCiAuU2ggTE9D QUxFIFNVUFBPUlQKIFRoZQogLk5tCkBAIC0zMjUsNiArMzgyLDEzIEBACiAuRHYgQU5ZCiBhZGRy ZXNzIGFuZCBSRkNPTU0gY2hhbm5lbAogLkxpIDEgLgorLkl0IGxuIC1zIEFyIC9ob21lL3dhbGxh YnkgQXIgL3Zhci9zcG9vbC9vYmV4LzAwOjAxOjAyOjAzOjA0OjA1CisuSXQgY2hvd24gLWggd2Fs bGFieSBBciAvdmFyL3Nwb29sL29iZXgvMDA6MDE6MDI6MDM6MDQ6MDUKK1doZW5ldmVyIHRoZSBk ZXZpY2Ugd2l0aCBCRF9BRERSIG9mIDAwOjAxOjAyOjAzOjA0OjA1IGNvbm5lY3RzLAorLk5tCity dW5uaW5nIGluIHNlcnZlciBtb2RlIHdpbGwgc3dpdGNoIHRvIHVzZXIgSUQKKy5BciB3YWxsYWJ5 CithbmQgdXNlIHRoZWlyIGhvbWUgZGlyZWN0b3J5IGFzIHRoZSB0b3AtbGV2ZWwgZm9yIHRoZSBj b25uZWN0aW9uLiAKIC5FbAogLlNzIExldmVsIDEgSW5mb3JtYXRpb24gQWNjZXNzCiBUaGUgZmly c3QgbGV2ZWwgaW52b2x2ZXMgdGhlIGJhc2ljIGFiaWxpdHkgdG8gcHV0IGFuIG9iamVjdCAoc3Vj aCBhcyBhIHZDYXJkKQpJbmRleDogb2JleGFwcC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC91c3Iv bG9jYWwvY3ZzL3BvcnRzL29iZXhhcHAvb2JleGFwcC5oLHYKcmV0cmlldmluZyByZXZpc2lvbiAx LjkKZGlmZiAtdSAtcjEuOSBvYmV4YXBwLmgKLS0tIG9iZXhhcHAuaAkyMyBBcHIgMjAwNyAxODoy OToxOCAtMDAwMAkxLjkKKysrIG9iZXhhcHAuaAkxNCBBcHIgMjAwOSAyMToyNjo0NCAtMDAwMApA QCAtMSw3ICsxLDcgQEAKIC8qCiAgKiBvYmV4YXBwLmgKICAqCi0gKiBDb3B5cmlnaHQgKGMpIDIw MDIgTWFrc2ltIFlldm1lbmtpbiA8bV9ldm1lbmtpbkB5YWhvby5jb20+CisgKiBDb3B5cmlnaHQg KGMpIDIwMDItMjAwOSBNYWtzaW0gWWV2bWVua2luIDxtX2V2bWVua2luQHlhaG9vLmNvbT4KICAq IEFsbCByaWdodHMgcmVzZXJ2ZWQuCiAgKgogICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBz b3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CkBAIC04Nyw5ICs4NywxMCBA QAogCXVuc2lnbmVkCQkgc2VydmVyICAgICA6IDE7IC8qIHNlcnZlciBtb2RlPyAqLwogCXVuc2ln bmVkCQkgc2VjdXJlICAgICA6IDE7IC8qIHNlY3VyZSBtb2RlPyAqLwogCXVuc2lnbmVkCQkgZG9u ZSAgICAgICA6IDE7IC8qIGRvbmU/ICovCi0JdW5zaWduZWQJCSBkZXRhY2ggICAgIDogMTsgLyog ZGV0YWNoIHNlcnZlcj8gKi8KIAl1bnNpZ25lZCAJCSBmYnMgICAgICAgIDogMTsgLyogRm9sZGVy IEJyb3dzaW5nIFNlcnZpY2UgKi8KLQl1bnNpZ25lZAkJIHJlc2VydmVkICAgOiAyOworCXVuc2ln bmVkCQkgdnJvb3QJICAgIDogMTsgLyogdmlydHVhbGl6ZSBkZXZpY2UncyByb290ICovCisJdW5z aWduZWQJCSBuaSAgICAgICAgIDogMTsgLyogbm9uLWludGVyYWN0aXZlPyAqLworCXVuc2lnbmVk CQkgcmVzZXJ2ZWQgICA6IDE7CiAKIAkvKiBsb2NhbCBTRFAgc2Vzc2lvbiAoc2VydmVyIG9ubHkp ICovCiAJdm9pZAkJCSpzczsKQEAgLTExMSw2ICsxMTIsMTAgQEAKIAl1aW50OF90CQkJKnNidWZm ZXI7CiAKIAlpbnQJCQkgbXR1OyAgICAgICAgICAgIC8qIE9CRVggTVRVICovCisKKwkvKiBjcmVk ZW50aWFscyAqLworCXVpZF90CQkJIHVpZDsKKwlnaWRfdAkJCSBnaWQ7CiB9OwogdHlwZWRlZiBz dHJ1Y3QgY29udGV4dAkJY29udGV4dF90OwogdHlwZWRlZiBzdHJ1Y3QgY29udGV4dCAqCWNvbnRl eHRfcDsKSW5kZXg6IHNlcnZlci5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC91c3IvbG9jYWwvY3Zz L3BvcnRzL29iZXhhcHAvc2VydmVyLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTEKZGlmZiAt dSAtcjEuMTEgc2VydmVyLmMKLS0tIHNlcnZlci5jCTkgQXByIDIwMDkgMjM6MTY6MzEgLTAwMDAJ MS4xMQorKysgc2VydmVyLmMJMTQgQXByIDIwMDkgMjA6NTU6MzcgLTAwMDAKQEAgLTEsNyArMSw3 IEBACiAvKgogICogc2VydmVyLmMKICAqCi0gKiBDb3B5cmlnaHQgKGMpIDIwMDIgTWFrc2ltIFll dm1lbmtpbiA8bV9ldm1lbmtpbkB5YWhvby5jb20+CisgKiBDb3B5cmlnaHQgKGMpIDIwMDItMjAw OSBNYWtzaW0gWWV2bWVua2luIDxtX2V2bWVua2luQHlhaG9vLmNvbT4KICAqIEFsbCByaWdodHMg cmVzZXJ2ZWQuCiAgKgogICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJp bmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CkBAIC04OSw2ICs4OSwxMCBAQAogc3RhdGljIGNo YXIgY29uc3QgKiBjb25zdAlsc19wYXJlbnRfZm9sZGVyID0KIAkiPHBhcmVudC1mb2xkZXIvPlxu IjsKIAorc3RhdGljIGludCBvYmV4YXBwX3NlcnZlcl9zZXRfaW5pdGlhbF9yb290IChjb250ZXh0 X3AgY29udGV4dCk7CitzdGF0aWMgaW50IG9iZXhhcHBfc2VydmVyX3NldF9kZXZpY2Vfcm9vdCAg KGNvbnRleHRfcCBjb250ZXh0KTsKK3N0YXRpYyBpbnQgb2JleGFwcF9zZXJ2ZXJfc2V0X2ZpbmFs X3Jvb3QgICAoY29udGV4dF9wIGNvbnRleHQpOworCiAvKiBPQkVYIHJlcXVlc3QgaGFuZGxlcnMg Ki8KIHN0YXRpYyBvYmV4YXBwX3JlcXVlc3RfaGFuZGxlcl90CW9iZXhhcHBfc2VydmVyX3JlcXVl c3RfY29ubmVjdDsKIHN0YXRpYyBvYmV4YXBwX3JlcXVlc3RfaGFuZGxlcl90CW9iZXhhcHBfc2Vy dmVyX3JlcXVlc3RfZGlzY29ubmVjdDsKQEAgLTExNCw3ICsxMTgsNiBAQAogb2JleGFwcF9zZXJ2 ZXIob2JleF90ICpoYW5kbGUpCiB7CiAJY29udGV4dF9wCQkgY29udGV4dCA9IChjb250ZXh0X3Ap IE9CRVhfR2V0VXNlckRhdGEoaGFuZGxlKTsKLQlzdHJ1Y3QgcGFzc3dkCQkqcHcgPSBOVUxMOwog CWludAkJCSBlcnJvciA9IC0xOwogCXN0cnVjdCBzb2NrYWRkcl9yZmNvbW0JIGFkZHI7CiAKQEAg LTEzMSwyNiArMTM0LDYgQEAKIAkJZ290byBkb25lOwogCX0KIAotCWlmIChjb250ZXh0LT51c2Vy ICE9IE5VTEwpIHsKLQkJaWYgKGF0b2koY29udGV4dC0+dXNlcikgIT0gMCkKLQkJCXB3ID0gZ2V0 cHd1aWQoYXRvaShjb250ZXh0LT51c2VyKSk7Ci0JCWVsc2UKLQkJCXB3ID0gZ2V0cHduYW0oY29u dGV4dC0+dXNlcik7Ci0KLQkJaWYgKHB3ID09IE5VTEwpIHsKLQkJCWxvZ19lcnIoIiVzKCk6IFVu a25vd24gdXNlciAlcyIsIF9fZnVuY19fLCAKLQkJCQljb250ZXh0LT51c2VyKTsKLQkJCWdvdG8g ZG9uZTsKLQkJfQotCX0KLQotCWlmIChjb250ZXh0LT5yb290WzBdID09ICdcMCcpIHsKLQkJaWYg KHB3ID09IE5VTEwpCi0JCQlzdHJsY3B5KGNvbnRleHQtPnJvb3QsIE9CRVhBUFBfUk9PVF9ESVIs IFBBVEhfTUFYKTsKLQkJZWxzZQotCQkJc3RybGNweShjb250ZXh0LT5yb290LCBwdy0+cHdfZGly LCBQQVRIX01BWCk7Ci0JfQotCiAJbG9nX2luZm8oIiVzOiBTdGFydGluZyBPQkVYIHNlcnZlciIs IF9fZnVuY19fKTsKIAogCWlmIChPQkVYX1NldFRyYW5zcG9ydE1UVShoYW5kbGUsIGNvbnRleHQt Pm10dSwgY29udGV4dC0+bXR1KSA8IDApIHsKQEAgLTE2Miw3ICsxNDUsNyBAQAogCWFkZHIucmZj b21tX2xlbiA9IHNpemVvZihhZGRyKTsKIAlhZGRyLnJmY29tbV9mYW1pbHkgPSBBRl9CTFVFVE9P VEg7CiAJYWRkci5yZmNvbW1fY2hhbm5lbCA9IGNvbnRleHQtPmNoYW5uZWw7Ci0JbWVtY3B5KCZh ZGRyLnJmY29tbV9iZGFkZHIsICZjb250ZXh0LT5yYWRkciwgc2l6ZW9mKGNvbnRleHQtPnJhZGRy KSk7CisJbWVtY3B5KCZhZGRyLnJmY29tbV9iZGFkZHIsICZjb250ZXh0LT5sYWRkciwgc2l6ZW9m KGNvbnRleHQtPmxhZGRyKSk7CiAKIAlpZiAoT0JFWF9TZXJ2ZXJSZWdpc3RlcihoYW5kbGUsIChz dHJ1Y3Qgc29ja2FkZHIgKikgJmFkZHIsCiAJCQlzaXplb2YoYWRkcikpIDwgMCkgewpAQCAtMTcw LDQwICsxNTMsMTIgQEAKIAkJZ290byBkb25lOwogCX0KIAotCWlmIChnZXR1aWQoKSA9PSAwKSB7 Ci0JCWlmIChjb250ZXh0LT5zZWN1cmUpIHsKLQkJCWlmIChjaHJvb3QoY29udGV4dC0+cm9vdCkg PCAwKSB7Ci0JCQkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IGNocm9vdCglcykuICVzICglZCki LAotCQkJCQlfX2Z1bmNfXywgY29udGV4dC0+cm9vdCwKLQkJCQkJc3RyZXJyb3IoZXJybm8pLCBl cnJubyk7Ci0JCQkJZ290byBkb25lOwotCQkJfQotCi0JCQlzdHJsY3B5KGNvbnRleHQtPnJvb3Qs ICIvIiwgUEFUSF9NQVgpOwotCQl9Ci0KLQkJaWYgKHB3ICE9IE5VTEwpIHsKLQkJCWlmIChzZXRn aWQocHctPnB3X2dpZCkgPCAwKSB7Ci0JCQkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IHNldGdp ZCglZCkuICVzICglZCkiLAotCQkJCQlfX2Z1bmNfXywgcHctPnB3X2dpZCwgc3RyZXJyb3IoZXJy bm8pLAotCQkJCQllcnJubyk7Ci0JCQkJZ290byBkb25lOwotCQkJfQotCi0JCQlpZiAoc2V0dWlk KHB3LT5wd191aWQpIDwgMCkgewotCQkJCWxvZ19lcnIoIiVzKCk6IENvdWxkIG5vdCBzZXR1aWQo JWQpLiAlcyAoJWQpIiwKLQkJCQkJX19mdW5jX18sIHB3LT5wd191aWQsIHN0cmVycm9yKGVycm5v KSwKLQkJCQkJZXJybm8pOwotCQkJCWdvdG8gZG9uZTsKLQkJCX0KLQkJfQotCX0KLQotCWlmIChj aGRpcihjb250ZXh0LT5yb290KSA8IDApIHsKLQkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IGNo ZGlyKCVzKS4gJXMgKCVkKSIsCi0JCQlfX2Z1bmNfXywgY29udGV4dC0+cm9vdCwgc3RyZXJyb3Io ZXJybm8pLCBlcnJubyk7CisJaWYgKG9iZXhhcHBfc2VydmVyX3NldF9pbml0aWFsX3Jvb3QoY29u dGV4dCkgPCAwKQorCQlnb3RvIGRvbmU7CisJaWYgKGNvbnRleHQtPnZyb290ICYmIG9iZXhhcHBf c2VydmVyX3NldF9kZXZpY2Vfcm9vdChjb250ZXh0KSA8IDApCisJCWdvdG8gZG9uZTsKKwlpZiAo b2JleGFwcF9zZXJ2ZXJfc2V0X2ZpbmFsX3Jvb3QoY29udGV4dCkgPCAwKQogCQlnb3RvIGRvbmU7 Ci0JfQogCiAJbG9nX2RlYnVnKCIlcygpOiBFbnRlcmluZyBldmVudCBwcm9jZXNzaW5nIGxvb3Au Li4iLCBfX2Z1bmNfXyk7CiAKQEAgLTIyNyw2ICsxODIsMTY1IEBACiB9IC8qIG9iZXhhcHBfc2Vy dmVyICovCiAKIC8qCisgKiBTZXQgaW5pdGlhbCBzZXJ2ZXIgcm9vdAorICovCisKK3N0YXRpYyBp bnQKK29iZXhhcHBfc2VydmVyX3NldF9pbml0aWFsX3Jvb3QoY29udGV4dF9wIGNvbnRleHQpCit7 CisJc3RydWN0IHBhc3N3ZAkqcHcgPSBOVUxMOworCWNoYXIJCSplcDsKKworCWlmIChjb250ZXh0 LT51c2VyICE9IE5VTEwpIHsKKwkJY29udGV4dC0+dWlkID0gc3RydG91bChjb250ZXh0LT51c2Vy LCAmZXAsIDEwKTsKKwkJaWYgKCplcCAhPSAnXDAnKQorCQkJcHcgPSBnZXRwd25hbShjb250ZXh0 LT51c2VyKTsKKwkJZWxzZQorCQkJcHcgPSBnZXRwd3VpZChjb250ZXh0LT51aWQpOworCisJCWlm IChwdyA9PSBOVUxMKSB7CisJCQlsb2dfZXJyKCIlcygpOiBVbmtub3duIHVzZXIgJyVzJyIsCisJ CQkJX19mdW5jX18sIGNvbnRleHQtPnVzZXIpOworCQkJcmV0dXJuICgtMSk7CisJCX0KKworCQls b2dfZGVidWcoIiVzKCk6IFJlcXVlc3RlZCB0byBydW4gYXMgJyVzJywgdWlkPSVkLCBnaWQ9JWQi LAorCQkJX19mdW5jX18sIGNvbnRleHQtPnVzZXIsIHB3LT5wd191aWQsIHB3LT5wd19naWQpOwor CisJCWNvbnRleHQtPnVpZCA9IHB3LT5wd191aWQ7CisJCWNvbnRleHQtPmdpZCA9IHB3LT5wd19n aWQ7CisJfSBlbHNlIHsKKwkJY29udGV4dC0+dWlkID0gZ2V0dWlkKCk7CisJCWNvbnRleHQtPmdp ZCA9IGdldGdpZCgpOworCX0KKworCS8qIFNldCBkZWZhdWx0IHJvb3QgKi8KKwlpZiAoY29udGV4 dC0+cm9vdFswXSA9PSAnXDAnKSB7CisJCWlmIChwdyA9PSBOVUxMKQorCQkJc3RybGNweShjb250 ZXh0LT5yb290LCBPQkVYQVBQX1JPT1RfRElSLCBQQVRIX01BWCk7CisJCWVsc2UKKwkJCXN0cmxj cHkoY29udGV4dC0+cm9vdCwgcHctPnB3X2RpciwgUEFUSF9NQVgpOworCX0KKworCWlmIChjaGRp cihjb250ZXh0LT5yb290KSA8IDApIHsKKwkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IGNoZGly KCVzKS4gJXMgKCVkKSIsCisJCQlfX2Z1bmNfXywgY29udGV4dC0+cm9vdCwgc3RyZXJyb3IoZXJy bm8pLCBlcnJubyk7CisJCXJldHVybiAoLTEpOworCX0KKworCWxvZ19kZWJ1ZygiJXMoKTogVXNp bmcgaW5pdGlhbCByb290ICVzIiwgX19mdW5jX18sIGNvbnRleHQtPnJvb3QpOworCisJcmV0dXJu ICgwKTsKK30gLyogb2JleGFwcF9zZXJ2ZXJfc2V0X2luaXRpYWxfcm9vdCAqLworCisvKgorICog U2V0IGRldmljZSBzcGVjaWZpYyBzZXJ2ZXIgcm9vdAorICovCisKK3N0YXRpYyBpbnQKK29iZXhh cHBfc2VydmVyX3NldF9kZXZpY2Vfcm9vdChjb250ZXh0X3AgY29udGV4dCkKK3sKKwljaGFyIGNv bnN0CSpyb290W10gPSB7IE5VTEwsIE5VTEwsIE5VTEwgfTsKKwlzdHJ1Y3QgaG9zdGVudAkqaGU7 CisJc3RydWN0IHN0YXQJc2I7CisJaW50CQluOworCisJbiA9IDA7CisKKwloZSA9IGJ0X2dldGhv c3RieWFkZHIoKGNoYXIgY29uc3QgKikgJmNvbnRleHQtPnJhZGRyLAorCQkJc2l6ZW9mKGJkYWRk cl90KSwgQUZfQkxVRVRPT1RIKTsKKwlpZiAoaGUgIT0gTlVMTCkKKwkJcm9vdFtuICsrXSA9IChj aGFyIGNvbnN0ICopIGhlLT5oX25hbWU7CisKKwlyb290W24gKytdID0gYnRfbnRvYSgmY29udGV4 dC0+cmFkZHIsIE5VTEwpOworCisJcm9vdFtuICsrXSA9ICJkZWZhdWx0IjsKKworCWZvciAobiA9 IDA7IG4gPCAzOyBuICsrKSB7CisJCWlmIChyb290W25dID09IE5VTEwpCisJCQlicmVhazsKKwor CQlsb2dfZGVidWcoIiVzKCk6IENoZWNraW5nIGZvciAlcy8lcyBzdWJkaXJlY3RvcnkiLAorCQkJ X19mdW5jX18sIGNvbnRleHQtPnJvb3QsIHJvb3Rbbl0pOworCisJCWlmIChsc3RhdChyb290W25d LCAmc2IpIDwgMCkgeworCQkJaWYgKGVycm5vID09IEVOT0VOVCkKKwkJCQljb250aW51ZTsKKwor CQkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IGxzdGF0KCVzLyVzKS4gJXMgKCVkKSIsCisJCQkJ X19mdW5jX18sIGNvbnRleHQtPnJvb3QsIHJvb3Rbbl0sCisJCQkJc3RyZXJyb3IoZXJybm8pLCBl cnJubyk7CisKKwkJCXJldHVybiAoLTEpOworCQl9CisKKwkJc3RybGNhdChjb250ZXh0LT5yb290 LCAiLyIsIFBBVEhfTUFYKTsKKwkJc3RybGNhdChjb250ZXh0LT5yb290LCByb290W25dLCBQQVRI X01BWCk7CisKKwkJaWYgKGNoZGlyKHJvb3Rbbl0pIDwgMCkgeworCQkJbG9nX2VycigiJXMoKTog Q291bGQgbm90IGNoZGlyKCVzKS4gJXMgKCVkKSIsCisJCQkJX19mdW5jX18sIGNvbnRleHQtPnJv b3QsIHN0cmVycm9yKGVycm5vKSwKKwkJCQllcnJubyk7CisJCQlyZXR1cm4gKC0xKTsKKwkJfQor CisJCS8qIElmIHVzZXIgd2FzIG5vdCBzZXQgYmVmb3JlLCB0YWtlIGl0IGZyb20gbHN0YXQoKSBk YXRhICovCisJCWlmIChjb250ZXh0LT51c2VyID09IE5VTEwpIHsKKwkJCWNvbnRleHQtPnVpZCA9 IHNiLnN0X3VpZDsKKwkJCWNvbnRleHQtPmdpZCA9IHNiLnN0X2dpZDsKKwkJfQorCisJCWxvZ19k ZWJ1ZygiJXMoKTogVXNpbmcgZGV2aWNlIHNwZWNpZmljIHJvb3QgJXMsIHVpZD0lZCwgZ2lkPSVk IiwKKwkJCV9fZnVuY19fLCBjb250ZXh0LT5yb290LCBjb250ZXh0LT51aWQsIGNvbnRleHQtPmdp ZCk7CisKKwkJcmV0dXJuICgxKTsKKwl9CisKKwlsb2dfZXJyKCIlcygpOiBDb3VsZCBub3QgZmlu ZCBkZXZpY2Ugc3BlY2lmaWMgcm9vdCBmb3IgdGhlIGRldmljZSAiIFwKKwkJImJkYWRkciAlcyAo JXMpIiwgX19mdW5jX18sIHJvb3RbMV0sCisJCXJvb3RbMF0/IHJvb3RbMF0gOiAiLW5vLW5hbWUt Iik7CisKKwlyZXR1cm4gKC0xKTsKK30gLyogb2JleGFwcF9zZXJ2ZXJfc2V0X2RldmljZV9yb290 ICovCisKKy8qCisgKiBGaW5hbGl6ZSBzZXJ2ZXIgcm9vdAorICovCisKK3N0YXRpYyBpbnQKK29i ZXhhcHBfc2VydmVyX3NldF9maW5hbF9yb290KGNvbnRleHRfcCBjb250ZXh0KQoreworCWlmIChj b250ZXh0LT5zZWN1cmUpIHsKKwkJaWYgKGNocm9vdChjb250ZXh0LT5yb290KSA8IDApIHsKKwkJ CWxvZ19lcnIoIiVzKCk6IENvdWxkIG5vdCBjaHJvb3QoJXMpLiAlcyAoJWQpIiwKKwkJCQlfX2Z1 bmNfXywgY29udGV4dC0+cm9vdCwKKwkJCQlzdHJlcnJvcihlcnJubyksIGVycm5vKTsKKwkJCXJl dHVybiAoLTEpOworCQl9CisKKwkJc3RybGNweShjb250ZXh0LT5yb290LCAiLyIsIFBBVEhfTUFY KTsKKwl9CisKKwlpZiAoY29udGV4dC0+Z2lkICE9IGdldGdpZCgpICYmIHNldGdpZChjb250ZXh0 LT5naWQpIDwgMCkgeworCQlsb2dfZXJyKCIlcygpOiBDb3VsZCBub3Qgc2V0Z2lkKCVkKS4gJXMg KCVkKSIsCisJCQlfX2Z1bmNfXywgY29udGV4dC0+Z2lkLCBzdHJlcnJvcihlcnJubyksIGVycm5v KTsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJaWYgKGNvbnRleHQtPnVpZCAhPSBnZXR1aWQoKSAm JiBzZXR1aWQoY29udGV4dC0+dWlkKSA8IDApIHsKKwkJbG9nX2VycigiJXMoKTogQ291bGQgbm90 IHNldHVpZCglZCkuICVzICglZCkiLAorCQkJX19mdW5jX18sIGNvbnRleHQtPnVpZCwgc3RyZXJy b3IoZXJybm8pLCBlcnJubyk7CisJCXJldHVybiAoLTEpOworCX0KKworCWxvZ19ub3RpY2UoIiVz KCk6IFVzaW5nIHJvb3QgJXM7IFNlY3VyZSBtb2RlICVzOyAiCisJCSJSdW5uaW5nIGFzIHVpZD0l ZCwgZ2lkPSVkIiwgX19mdW5jX18sIGNvbnRleHQtPnJvb3QsCisJCWNvbnRleHQtPnNlY3VyZT8g ImVuYWJsZWQiIDogImRpc2FibGVkIiwgZ2V0dWlkKCksIGdldGdpZCgpKTsKKworCXJldHVybiAo MCk7Cit9IC8qIG9iZXhhcHBfc2VydmVyX3NldF9maW5hbF9yb290ICovCisKKy8qCiAgKiBQcm9j ZXNzIE9CRVhfRVZfUkVRSElOVCBldmVudAogICovCiAKQEAgLTU2NSw2ICs2NzksMTUgQEAKIAkJ CX0KIAkJfQogCisJCWlmIChjaG1vZChjb250ZXh0LT50ZW1wLCBTX0lSVVNSfFNfSVdVU1J8U19J UkdSUHxTX0lXR1JQKSA8IDApIHsKKwkJCWxvZ19lcnIoIiVzKCk6IENvdWxkIG5vdCBjaG1vZCgl cykuICVzICglZCkiLAorCQkJCV9fZnVuY19fLCBjb250ZXh0LT50ZW1wLAorCQkJCXN0cmVycm9y KGVycm5vKSwgZXJybm8pOworCisJCQljb2RlcyA9IG9iZXhhcHBfdXRpbF9lcnJubzJyZXNwb25z ZShlcnJubyk7CisJCQlnb3RvIGRvbmU7CisJCX0KKwogCQlpZiAocmVuYW1lKGNvbnRleHQtPnRl bXAsIGNvbnRleHQtPmZpbGUpIDwgMCkgewogCQkJbG9nX2VycigiJXMoKTogQ291bGQgbm90IHJl bmFtZSglcywgJXMpLiAlcyAoJWQpIiwKIAkJCQlfX2Z1bmNfXywgY29udGV4dC0+dGVtcCwKSW5k ZXg6IHRyYW5zcG9ydC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC91c3IvbG9jYWwvY3ZzL3BvcnRz L29iZXhhcHAvdHJhbnNwb3J0LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTMKZGlmZiAtdSAt cjEuMTMgdHJhbnNwb3J0LmMKLS0tIHRyYW5zcG9ydC5jCTIxIE1heSAyMDA3IDE1OjU1OjM1IC0w MDAwCTEuMTMKKysrIHRyYW5zcG9ydC5jCTE0IEFwciAyMDA5IDIxOjI2OjAyIC0wMDAwCkBAIC0x LDcgKzEsNyBAQAogLyoKICAqIHRyYW5zcG9ydC5jCiAgKgotICogQ29weXJpZ2h0IChjKSAyMDAx IE1ha3NpbSBZZXZtZW5raW4gPG1fZXZtZW5raW5AeWFob28uY29tPgorICogQ29weXJpZ2h0IChj KSAyMDAxLTIwMDkgTWFrc2ltIFlldm1lbmtpbiA8bV9ldm1lbmtpbkB5YWhvby5jb20+CiAgKiBB bGwgcmlnaHRzIHJlc2VydmVkLgogICoKICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291 cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dApAQCAtMjgwLDYgKzI4MCw5IEBA CiAJCQkJcmV0dXJuICgtMSk7CiAJCQl9CiAKKwkJCW1lbWNweSgmY29udGV4dC0+cmFkZHIsICZh ZGRyLnJmY29tbV9iZGFkZHIsCisJCQkJc2l6ZW9mKGNvbnRleHQtPnJhZGRyKSk7CisKIAkJCXJl dHVybiAoMSk7CiAJCX0KIApJbmRleDogdXRpbC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC91c3Iv bG9jYWwvY3ZzL3BvcnRzL29iZXhhcHAvdXRpbC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE0 CmRpZmYgLXUgLXIxLjE0IHV0aWwuYwotLS0gdXRpbC5jCTEwIEFwciAyMDA5IDE3OjI2OjAzIC0w MDAwCTEuMTQKKysrIHV0aWwuYwkxNCBBcHIgMjAwOSAyMToyNjowOCAtMDAwMApAQCAtMSw3ICsx LDcgQEAKIC8qCiAgKiB1dGlsLmMKICAqCi0gKiBDb3B5cmlnaHQgKGMpIDIwMDIgTWFrc2ltIFll dm1lbmtpbiA8bV9ldm1lbmtpbkB5YWhvby5jb20+CisgKiBDb3B5cmlnaHQgKGMpIDIwMDItMjAw OSBNYWtzaW0gWWV2bWVua2luIDxtX2V2bWVua2luQHlhaG9vLmNvbT4KICAqIEFsbCByaWdodHMg cmVzZXJ2ZWQuCiAgKgogICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJp bmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CkBAIC00MjUsOSArNDI1LDcgQEAKIAkgKiBzdHJp bmcsIHNvIGFsd2F5cyBwYXNzIGEgY29weS4KIAkgKi8KIAotCXN0cm5jcHkobiwgbmFtZSwgc2l6 ZW9mKG4pKTsKLQluW3NpemVvZihuKSAtIDFdID0gJ1wwJzsKLQorCXN0cmxjcHkobiwgbmFtZSwg c2l6ZW9mKG4pKTsKIAlzbnByaW50Zih0ZW1wLCB0ZW1wX3NpemUsICIlcy9YWFhYWFhYWCIsIGRp cm5hbWUobikpOwogCiAJcmV0dXJuIChta3N0ZW1wKHRlbXApKTsK --0016361e7db21a795504678aa701-- From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 22:12:46 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 702BE106564A for ; Tue, 14 Apr 2009 22:12:46 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 475C28FC0A for ; Tue, 14 Apr 2009 22:12:46 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 14216 invoked from network); 14 Apr 2009 22:12:45 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 22:12:45 -0000 Message-ID: <49E50A59.9000606@aldan.algebra.com> Date: Tue, 14 Apr 2009 18:12:41 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Maksim Yevmenkin References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <49E4CAE1.6090506@aldan.algebra.com> <49E4EA14.80300@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 22:12:46 -0000 Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): > hopefully the latest patch will work for everyone. > Little nits this time... 1. Even when the service is not running as root to begin with (and thus chroot is impossible), a user owning multiple devices may wish to have separate directories for each one. Yet, the new -R switch, as proposed, requires successful chroot into a matching entry... It does not need to. How about: + case 'R': /* virtualize root for each device */ + context.vroot = 1; + if (getuid() == 0) + context.secure = 1; + break; + chdir should be used instead of chroot in this case (-R was given, and a matching entry is found, but we aren't running as root). 2. When going through the list of possible subdirectories-candidates, hardcoding the number 3 is a bit dangerous. Using either sizeof(root)/sizeof(root[0]) or simply going, until hitting NULL: char const *root[] = { NULL, NULL, NULL, NULL }, **r; ... foreach (r -> root; *r; r++) { log_debug("%s(): Checking for %s/%s subdirectory", __func__, context->root, *r); ... would be a bit safer going forward -- what if some other parameter (such as an environment variable) may some day be added to the list of considerations? 3. After starting up, with the -R (or the -r) option, should/does not the daemon chdir into the specified top-level directory? And if so, there is no need to assemble the context->root with strlcat -- just perform chdir into the relative root[n] (or *r in my example). The chroot can then happen to ".". After chdir-ing, you can populate the actual contet->root with getcwd(context->root, PATH_MAX) -- a faster equivalent to using realpath(3). This is not material, but the fewer cases, where a hard-coded PATH_MAX is used instead of the POSIX-approved pathconf(2), the better... Yours, -mi P.S. Thank you very much for keeping the wallabies in the manual's examples. Better creatures are not to be found, and it is certainly nicer to use them instead of the ubiquitous "foo" and "bar". From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 22:46:44 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744141065691 for ; Tue, 14 Apr 2009 22:46:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 26D208FC14 for ; Tue, 14 Apr 2009 22:46:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1673447ywh.13 for ; Tue, 14 Apr 2009 15:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d2Z9dNz4/SwqDVZsZL1Yzx/8b+sDPymqDaS6h6zSG1A=; b=q+x6zCoW8onfC0/GZNSIz0T1WX7V4b+1PRMhKCsIR1uR3Pc8LyPa3fkvfWNrgsN9O+ Ep94Cznw32Oh8luoDTjv6/hPOSAbzc2eTIotB64DE4UXWul2WiHBYp4dem9AIFIHZU2X uDvJW7QOdK+xHH4Ogy2PRmJG3LnlGS0dkFncU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LjCBfx0LWRFzOoqvPCKuQXq7mTMHWJG35b7PJ283gOcuvhnHm1+NBXaYRsyw7fGw2r ng35TyG0caWqSaezO6KJGG+Pqsr0deIR+vENwE/XStYsRCNrTcDLJ8d54aEBTaKJf9ev 684toDzizxXBtbeBQ0wOFusX5G/cWBkWinFUg= MIME-Version: 1.0 Received: by 10.90.68.12 with SMTP id q12mr6201929aga.79.1239749203516; Tue, 14 Apr 2009 15:46:43 -0700 (PDT) In-Reply-To: <49E50A59.9000606@aldan.algebra.com> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <49E4CAE1.6090506@aldan.algebra.com> <49E4EA14.80300@aldan.algebra.com> <49E50A59.9000606@aldan.algebra.com> Date: Tue, 14 Apr 2009 15:46:43 -0700 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 22:46:45 -0000 2009/4/14 Mikhail T. : > Maksim Yevmenkin =CE=C1=D0=C9=D3=C1=D7(=CC=C1): >> hopefully the latest patch will work for everyone. >> > Little nits this time... > > 1. Even when the service is not running as root to begin with (and thus > chroot is impossible), a user owning multiple devices may wish to have > separate directories for each one. Yet, the new -R switch, as proposed, > requires successful chroot into a matching entry... It does not need to. > How about: > > + case 'R': /* virtualize root for each device */ > + context.vroot =3D 1; > + if (getuid() =3D=3D 0) > + context.secure =3D 1; > + break; > + > > chdir should be used instead of chroot in this case (-R was given, and a > matching entry is found, but we aren't running as root). well, a couple of things. for now, we always have to start obexapp as root because it needs to talk to sdpd(8) to register services. sdpd(8) is checking credentials (passed via unix sockets) and makes sure that the process, that is trying to register the service, has uid of 'root' user. so, strictly speaking this change is a no-op because getuid() will always be 0 or else obexapp will not start in server mode. also, i'd _really_ like to keep clients "jailed" under their virtual root folders. at least for now. as far as keeping and sharing files under the same root folder, i just thought of a way to "break" the latest patch: set up symlink that points to '.' under default root folder. obviously chdir() and chroot() conditions will be satisfied and you get your files dumped in the same directory. > 2. When going through the list of possible subdirectories-candidates, > hardcoding the number 3 is a bit dangerous. Using either > > sizeof(root)/sizeof(root[0]) > > or simply going, until hitting NULL: > > char const *root[] =3D { NULL, NULL, NULL, NULL }, **r; > ... > foreach (r -> root; *r; r++) { > > log_debug("%s(): Checking for %s/%s subdirectory", > __func__, context->root, *r); > ... > > would be a bit safer going forward -- what if some other parameter (such > as an environment variable) may some day be added to the list of > considerations? that's fine. i will fix it. > 3. After starting up, with the -R (or the -r) option, should/does not > the daemon chdir into the specified top-level directory? And if so, > there is no need to assemble the context->root with strlcat -- just > perform chdir into the relative root[n] (or *r in my example). The > chroot can then happen to ".". After chdir-ing, you can populate the > actual contet->root with getcwd(context->root, PATH_MAX) -- a faster > equivalent to using realpath(3). it does, chdir(), i.e. obexapp_server_set_initial_root() does it. strlcat() is not that expensive, imo. it can be changed, i guess. > This is not material, but the fewer cases, where a hard-coded PATH_MAX > is used instead of the POSIX-approved pathconf(2), the better... PATH_MAX comes from sys/syslimits.h, so, i thought it would be ok to use. another alternative was MAXPATHLEN which was the same. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 23:13:31 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA39F1065670 for ; Tue, 14 Apr 2009 23:13:31 +0000 (UTC) (envelope-from mwm-dated-1240613108.05b150@mired.org) Received: from mired.org (two.mired.org [74.143.213.43]) by mx1.freebsd.org (Postfix) with ESMTP id 751A68FC1E for ; Tue, 14 Apr 2009 23:13:31 +0000 (UTC) (envelope-from mwm-dated-1240613108.05b150@mired.org) Received: (qmail 17462 invoked by uid 1001); 14 Apr 2009 18:45:08 -0400 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda (tmda-ofmipd) with ESMTP; Tue, 14 Apr 2009 18:45:07 -0400 Date: Tue, 14 Apr 2009 18:45:07 -0400 To: Maksim Yevmenkin Message-ID: <20090414184507.5afc4a88@bhuda.mired.org> In-Reply-To: References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> Organization: Meyer Consulting X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd7.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Mike Meyer Cc: "freebsd-bluetooth@freebsd.org" , "Mikhail T." Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:13:32 -0000 On Tue, 14 Apr 2009 09:34:43 -0700 Maksim Yevmenkin wrote: > > Maksim Yevmenkin =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2(=D0=BB=D0= =B0): > > because all of the bluetooth users would have to be listed in obex' > > group and so there can be no more than 20 of them (I think, that's the > > limit on a group size). Just so this doesn't wind up being quoted as accurate: There are no limits on how many people can be in a group. There is a limit on how many groups a person can be in (or was; I haven't verified that this hasn't been changed recently). BSD was used at UC Berkeley (the B in BSD) on machines with thousands of users, and groups with hundreds of members. We had to db'ify the password file, but the groups code worked just fine. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 23:22:27 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F141106567D for ; Tue, 14 Apr 2009 23:22:27 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by mx1.freebsd.org (Postfix) with ESMTP id 050928FC0A for ; Tue, 14 Apr 2009 23:22:26 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 24381 invoked from network); 14 Apr 2009 23:22:26 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 23:22:25 -0000 Message-ID: <49E51AAF.4060907@aldan.algebra.com> Date: Tue, 14 Apr 2009 19:22:23 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Maksim Yevmenkin References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <49E4CAE1.6090506@aldan.algebra.com> <49E4EA14.80300@aldan.algebra.com> <49E50A59.9000606@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:22:27 -0000 Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): > 2009/4/14 Mikhail T. : > >> Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): >> >>> hopefully the latest patch will work for everyone. >>> >> Little nits this time... >> >> 1. Even when the service is not running as root to begin with (and thus >> chroot is impossible), a user owning multiple devices may wish to have >> separate directories for each one. Yet, the new -R switch, as proposed, >> requires successful chroot into a matching entry... It does not need to. >> How about: >> >> + case 'R': /* virtualize root for each device */ >> + context.vroot = 1; >> + if (getuid() == 0) >> + context.secure = 1; >> + break; >> + >> >> chdir should be used instead of chroot in this case (-R was given, and a >> matching entry is found, but we aren't running as root). >> > > well, a couple of things. for now, we always have to start obexapp as > root because it needs to talk to sdpd(8) to register services. sdpd(8) > is checking credentials (passed via unix sockets) and makes sure that > the process, that is trying to register the service, has uid of 'root' > user. so, strictly speaking this change is a no-op because getuid() > will always be 0 or else obexapp will not start in server mode. > Oh, that must be why I couldn't start obexapp as myself before... So, all of those getuid() calls are no-ops too? Either they need to be eliminated, or, if other ways of authenticating to sdp are in the works, ability to chroot should not be a requirement. > also, i'd _really_ like to keep clients "jailed" under their virtual > root folders. at least for now. as far as keeping and sharing files > under the same root folder, i just thought of a way to "break" the > latest patch: set up symlink that points to '.' under default root > folder. obviously chdir() and chroot() conditions will be satisfied > and you get your files dumped in the same directory. > Right, of course. The symlinks can point to . or to some external /home/dropoff -- same thing. > >> 3. After starting up, with the -R (or the -r) option, should/does not >> the daemon chdir into the specified top-level directory? And if so, >> there is no need to assemble the context->root with strlcat -- just >> perform chdir into the relative root[n] (or *r in my example). The >> chroot can then happen to ".". After chdir-ing, you can populate the >> actual contet->root with getcwd(context->root, PATH_MAX) -- a faster >> equivalent to using realpath(3). >> > > it does, chdir(), i.e. obexapp_server_set_initial_root() does it. > strlcat() is not that expensive, imo. it can be changed, i guess. > It is not expensive, but not needed either :) After a chdir succeeds, the chroot can go simply into "." >> This is not material, but the fewer cases, where a hard-coded PATH_MAX >> is used instead of the POSIX-approved pathconf(2), the better... >> > PATH_MAX comes from sys/syslimits.h, so, i thought it would be ok to > use. another alternative was MAXPATHLEN which was the same. > The gist of the PATH_MAX/MAXPATHLEN vs. pathconf() controversy is that the latter may change after the program is compiled. Thus relying on ANY compile-time buffer-length as being "long enough" is potentially dangerous (and almost always wasteful). Logging the actual directory (as can be determined by getwd(NULL) after chdir-ing, but before chroot-ing), rather than the name of the symlink can be seen as beneficial too. Yours, -mi From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 23:29:42 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF9C81065674 for ; Tue, 14 Apr 2009 23:29:42 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 9397C8FC15 for ; Tue, 14 Apr 2009 23:29:42 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 16476 invoked from network); 14 Apr 2009 23:29:41 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 23:29:41 -0000 Message-ID: <49E51C60.5020302@aldan.algebra.com> Date: Tue, 14 Apr 2009 19:29:36 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Mike Meyer References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <20090414184507.5afc4a88@bhuda.mired.org> In-Reply-To: <20090414184507.5afc4a88@bhuda.mired.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "freebsd-bluetooth@freebsd.org" Subject: group-related limits (Re: RFC: obexapp - virtual root folder for each device) X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:29:43 -0000 Mike Meyer написав(Π»Π°): > On Tue, 14 Apr 2009 09:34:43 -0700 > Maksim Yevmenkin wrote: > > >>> Maksim Yevmenkin написав(Π»Π°): >>> because all of the bluetooth users would have to be listed in obex' >>> group and so there can be no more than 20 of them (I think, that's the >>> limit on a group size). >>> > > Just so this doesn't wind up being quoted as accurate: > > There are no limits on how many people can be in a group. There is a > limit on how many groups a person can be in (or was; I haven't > verified that this hasn't been changed recently). Thanks for the correction, Mike. I had only a vague memory of there being some limits related to groups -- from years ago :-) But still, if a person can only participate in so many groups, forcing participation in yet another one for common, non-administrative functionality should be avoided... Fortunately, we seem to have just agreed on a more straightforward way anyway. Yours, -mi From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 15 07:20:15 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2EE0106566B for ; Wed, 15 Apr 2009 07:20:15 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 5FACF8FC1C for ; Wed, 15 Apr 2009 07:20:15 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1LtzPf-000261-3T; Wed, 15 Apr 2009 08:20:03 +0100 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08011-02; Wed, 15 Apr 2009 08:20:02 +0100 (BST) Received: from [10.214.38.215] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1LtzPd-00025X-3q; Wed, 15 Apr 2009 08:20:02 +0100 Received: (nullmailer pid 692 invoked by uid 1000); Wed, 15 Apr 2009 07:18:49 -0000 Date: Wed, 15 Apr 2009 08:18:49 +0100 (BST) To: "Mikhail T\." In-Reply-To: <49E51C60.5020302@aldan.algebra.com> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <20090414184507.5afc4a88@bhuda.mired.org> <49E51C60.5020302@aldan.algebra.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-103377771-1239779929=:575" Message-Id: <1239779929.872107.654.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" , Mike Meyer Subject: Re: group-related limits (Re: RFC: obexapp - virtual root folder for each device) X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 07:20:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-103377771-1239779929=:575 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 14 Apr 2009, Mikhail T. wrote: > Mike Meyer =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF(=FF=FF=FF=FF): > > There are no limits on how many people can be in a group. There is a > > limit on how many groups a person can be in (or was; I haven't > > verified that this hasn't been changed recently). > > Thanks for the correction, Mike. I had only a vague memory of there > being some limits related to groups -- from years ago :-) I don't know about FreeBSD but on NetBSD there is AFAIK no limit to the number of groups that a user can be in. The "20 groups" limit comes from NFS which used a fixed array in its specifications (and so is a problem on any operating system) iain --0-103377771-1239779929=:575-- From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 15 20:59:36 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1852D1065672 for ; Wed, 15 Apr 2009 20:59:36 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 98E108FC16 for ; Wed, 15 Apr 2009 20:59:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so71065ywh.13 for ; Wed, 15 Apr 2009 13:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=SF5BNUDS+6vWfY4hR5M6WHNkcGdyDlPGcFQQDpFD/Ug=; b=iuScQBuFuZofBtixpudLC8il5u92VeykgnGAGOXxCyuNhpzLq4qeEaKftLuXKLWMz+ kJFQOWQQnLy1yUtw3Arq4kX1TGqn8F3Jq0iOsv81LWC7u0ubH+Ij/wPiYfuPK6rAelC0 Tv2ztjhUxF7/wR+iMYKycfVydp7HZ5+tiRQKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OXwHA8FHFCDqW2dsVnwv/Le8Vxub6jRJxF0V4JaEuZvVlkZNBSX0PhtsV47s96btyV hni1FmnNKy2WYVvN2M8tuogZeRiHhGuQtb/Pe0gJIiDZMsqbLOeS9UeBFM2N1tRYQ9xz u6b+BkunemnYrkssm8QrqKpNT2RaMVVMDurnA= MIME-Version: 1.0 Received: by 10.90.72.3 with SMTP id u3mr709935aga.83.1239829175008; Wed, 15 Apr 2009 13:59:35 -0700 (PDT) In-Reply-To: References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4E2F.2000805@incunabulum.net> <49DE6D42.6000004@incunabulum.net> Date: Wed, 15 Apr 2009 13:59:34 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert , "freebsd-bluetooth@freebsd.org" Content-Type: multipart/mixed; boundary=00163630f1d78efeb804679e39d2 Cc: Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:59:36 -0000 --00163630f1d78efeb804679e39d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit dear freebsd-bluetoth@ users, please find attached patch that implements more compatibility shims. any comments are greatly appreciated. thanks max --00163630f1d78efeb804679e39d2 Content-Type: text/plain; charset=US-ASCII; name="bluetooth.hci.diff(2).txt" Content-Disposition: attachment; filename="bluetooth.hci.diff(2).txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ftki9mu21 SW5kZXg6IGhjaS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGhjaS5jCShyZXZpc2lvbiAxOTA4NzApCisrKyBo Y2kuYwkod29ya2luZyBjb3B5KQpAQCAtMzAsMTUgKzMwLDQyMSBAQAogICogJEZyZWVCU0QkCiAg Ki8KIAorI2luY2x1ZGUgPGFzc2VydC5oPgogI2luY2x1ZGUgPGJsdWV0b290aC5oPgogI2luY2x1 ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAj aW5jbHVkZSA8dW5pc3RkLmg+CiAKK3N0YXRpYyBpbnQgICAgYnRfZGV2YW55X2NiKGludCBzLCBz dHJ1Y3QgYnRfZGV2aW5mbyBjb25zdCAqZGksIHZvaWQgKnhkZXZuYW1lKTsKIHN0YXRpYyBjaGFy ICogYnRfZGV2Mm5vZGUgKGNoYXIgY29uc3QgKmRldm5hbWUsIGNoYXIgKm5vZGVuYW1lLCBpbnQg bm5sZW4pOwogCiBpbnQKK2J0X2Rldm9wZW4oY2hhciBjb25zdCAqZGV2bmFtZSkKK3sKKwlzdHJ1 Y3Qgc29ja2FkZHJfaGNpCWhhOworCWJkYWRkcl90CQliYTsKKwlpbnQJCQlzOworCisJaWYgKGRl dm5hbWUgPT0gTlVMTCkgeworCQllcnJubyA9IEVJTlZBTDsKKwkJcmV0dXJuICgtMSk7CisJfQor CisJbWVtc2V0KCZoYSwgMCwgc2l6ZW9mKGhhKSk7CisJaGEuaGNpX2xlbiA9IHNpemVvZihoYSk7 CisJaGEuaGNpX2ZhbWlseSA9IEFGX0JMVUVUT09USDsKKworCWlmIChidF9hdG9uKGRldm5hbWUs ICZiYSkpIHsKKwkJaWYgKCFidF9kZXZuYW1lKGhhLmhjaV9ub2RlLCAmYmEpKQorCQkJcmV0dXJu ICgtMSk7CisJfSBlbHNlIGlmIChidF9kZXYybm9kZShkZXZuYW1lLCBoYS5oY2lfbm9kZSwKKwkJ CQkJc2l6ZW9mKGhhLmhjaV9ub2RlKSkgPT0gTlVMTCkgeworCQllcnJubyA9IEVOWElPOworCQly ZXR1cm4gKC0xKTsKKwl9CisKKwlzID0gc29ja2V0KFBGX0JMVUVUT09USCwgU09DS19SQVcsIEJM VUVUT09USF9QUk9UT19IQ0kpOworCWlmIChzIDwgMCkKKwkJcmV0dXJuICgtMSk7CisKKwlpZiAo YmluZChzLCAoc3RydWN0IHNvY2thZGRyICopICZoYSwgc2l6ZW9mKGhhKSkgPCAwIHx8CisJICAg IGNvbm5lY3QocywgKHN0cnVjdCBzb2NrYWRkciAqKSAmaGEsIHNpemVvZihoYSkpIDwgMCkgewor CQljbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuIChzKTsKK30KKworaW50 CitidF9kZXZjbG9zZShpbnQgcykKK3sKKwlyZXR1cm4gKGNsb3NlKHMpKTsKK30KKworaW50Citi dF9kZXZzZW5kKGludCBzLCB1aW50MTZfdCBvZ2YsIHVpbnQxNl90IG9jZiwgaW50IHBsZW4sIHZv aWQgKnBhcmFtKQoreworCW5nX2hjaV9jbWRfcGt0X3QJaDsKKwlzdHJ1Y3QgaW92ZWMJCWl2WzJd OworCWludAkJCWl2bjsKKworCWlmIChwbGVuIDwgMCB8fCAocGxlbiA+IDAgJiYgcGFyYW0gPT0g TlVMTCkpIHsgCisJCWVycm5vID0gRUlOVkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlpdlsw XS5pb3ZfYmFzZSA9ICZoOworCWl2WzBdLmlvdl9sZW4gPSBzaXplb2YoaCk7CisJaXZuID0gMTsK KworCWgudHlwZSA9IE5HX0hDSV9DTURfUEtUOworCWgub3Bjb2RlID0gaHRvbGUxNihOR19IQ0lf T1BDT0RFKG9nZiwgb2NmKSk7CisJaWYgKHBsZW4gPiAwKSB7CisJCWgubGVuZ3RoID0gcGxlbjsK KworCQlpdlsxXS5pb3ZfYmFzZSA9IHBhcmFtOworCQlpdlsxXS5pb3ZfbGVuID0gcGxlbjsKKwkJ aXZuID0gMjsKKwl9IGVsc2UKKwkJaC5sZW5ndGggPSAwOworCisJd2hpbGUgKHdyaXRldihzLCBp diwgaXZuKSA8IDApIHsKKwkJaWYgKGVycm5vID09IEVBR0FJTiB8fCBlcnJubyA9PSBFSU5UUikK KwkJCWNvbnRpbnVlOworCisJCXJldHVybiAoLTEpOworCX0KKworCXJldHVybiAoMCk7Cit9CisK K2ludAorYnRfZGV2cmVjdihpbnQgcywgdWludDhfdCAqYnVmLCBpbnQgc2l6ZSwgdGltZV90IHRv KQoreworCWZkX3NldAkJcmZkOworCXN0cnVjdCB0aW1ldmFsCXR2OworCWludAkJbjsKKworCWlm IChidWYgPT0gTlVMTCB8fCBzaXplIDw9IDAgfHwgdG8gPCAwKSB7CisJCWVycm5vID0gRUlOVkFM OworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlGRF9aRVJPKCZyZmQpOworCUZEX1NFVChzLCAmcmZk KTsKKworCXR2LnR2X3NlYyA9IHRvOworCXR2LnR2X3VzZWMgPSAwOworCisJd2hpbGUgKChuID0g c2VsZWN0KHMgKyAxLCAmcmZkLCBOVUxMLCBOVUxMLCAmdHYpKSA8IDApIHsKKwkJaWYgKGVycm5v ID09IEVBR0FJTiB8fCBlcnJubyA9PSBFSU5UUikKKwkJCWNvbnRpbnVlOworCisJCXJldHVybiAo LTEpOworCX0KKworCWlmIChuID09IDApIHsKKwkJZXJybm8gPSBFVElNRURPVVQ7CisJCXJldHVy biAoLTEpOworCX0KKworCWFzc2VydChGRF9JU1NFVChzLCAmcmZkKSk7CisKKwl3aGlsZSAoKG4g PSByZWFkKHMsIGJ1Ziwgc2l6ZSkpIDwgMCkgeworCQlpZiAoZXJybm8gPT0gRUFHQUlOIHx8IGVy cm5vID09IEVJTlRSKQorCQkJY29udGludWU7CisKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0 dXJuIChuKTsKK30KKworaW50CitidF9kZXZyZXEoaW50IHMsIHN0cnVjdCBidF9kZXZyZXEgKnIs IHRpbWVfdCB0bykKK3sKKwl1aW50OF90CQkJCWJ1ZlszMjBdOyAvKiBtb3JlIHRoYW4gZW5vdWdo ICovCisJbmdfaGNpX2V2ZW50X3BrdF90CQkqZSA9IChuZ19oY2lfZXZlbnRfcGt0X3QgKikgYnVm OworCW5nX2hjaV9jb21tYW5kX2NvbXBsX2VwCQkqY2MgPSAobmdfaGNpX2NvbW1hbmRfY29tcGxf ZXAgKikoZSsxKTsKKwluZ19oY2lfY29tbWFuZF9zdGF0dXNfZXAJKmNzID0gKG5nX2hjaV9jb21t YW5kX3N0YXR1c19lcCopKGUrMSk7CisJdWludDE2X3QJCQlvcGNvZGU7CisJdGltZV90CQkJCXRf ZW5kOworCWludAkJCQluOworCisJaWYgKHMgPCAwIHx8IHIgPT0gTlVMTCB8fCB0byA8IDApIHsK KwkJZXJybm8gPSBFSU5WQUw7CisJCXJldHVybiAoLTEpOworCX0KKworCWlmIChyLT5ybGVuIDwg MCB8fCAoci0+cmxlbiA+IDAgJiYgci0+cnBhcmFtID09IE5VTEwpKSB7CisJCWVycm5vID0gRUlO VkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwluID0gYnRfZGV2c2VuZChzLCByLT5vZ2YsIHIt Pm9jZiwgci0+Y2xlbiwgci0+Y3BhcmFtKTsKKwlpZiAobiA8IDApCisJCXJldHVybiAoLTEpOwor CisJb3Bjb2RlID0gaHRvbGUxNihOR19IQ0lfT1BDT0RFKHItPm9nZiwgci0+b2NmKSk7CisKKwl0 X2VuZCA9IHRpbWUoTlVMTCkgKyB0bzsKKworCWRvIHsKKwkJdG8gPSB0X2VuZCAtIHRpbWUoTlVM TCk7CisJCWlmICh0byA8IDApCisJCQl0byA9IDA7CisKKwkJbiA9IGJ0X2RldnJlY3YocywgYnVm LCBzaXplb2YoYnVmKSwgdG8pOworCQlpZiAobiA8IDApCisJCQlyZXR1cm4gKC0xKTsKKworCQlp ZiAobiA8IHNpemVvZigqZSkpIHsKKwkJCWVycm5vID0gRU1TR1NJWkU7CisJCQlyZXR1cm4gKC0x KTsKKwkJfQorCisJCWlmIChlLT50eXBlICE9IE5HX0hDSV9FVkVOVF9QS1QpIHsKKwkJCWVycm5v ID0gRUlPOworCQkJcmV0dXJuICgtMSk7CisJCX0KKworCQluIC09IHNpemVvZigqZSk7CisKKwkJ c3dpdGNoIChlLT5ldmVudCkgeworCQljYXNlIE5HX0hDSV9FVkVOVF9DT01NQU5EX0NPTVBMOgor CQkJaWYgKGNjLT5vcGNvZGUgPT0gb3Bjb2RlKSB7CisJCQkJbiAtPSBzaXplb2YoKmNjKTsKKwor CQkJCWlmIChyLT5ybGVuID49IG4pIHsKKwkJCQkJci0+cmxlbiA9IG47CisJCQkJCW1lbWNweShy LT5ycGFyYW0sIGNjICsgMSwgci0+cmxlbik7CisJCQkJfQorCisJCQkJcmV0dXJuICgwKTsKKwkJ CX0KKwkJCWJyZWFrOworCisJCWNhc2UgTkdfSENJX0VWRU5UX0NPTU1BTkRfU1RBVFVTOgorCQkJ aWYgKGNzLT5vcGNvZGUgPT0gb3Bjb2RlKSB7CisJCQkJaWYgKHItPmV2ZW50ICE9IE5HX0hDSV9F VkVOVF9DT01NQU5EX1NUQVRVUykgeworCQkJCQlpZiAoY3MtPnN0YXR1cyAhPSAwKSB7CisJCQkJ CQllcnJubyA9IEVJTzsKKwkJCQkJCXJldHVybiAoLTEpOworCQkJCQl9CisJCQkJfSBlbHNlIHsK KwkJCQkJaWYgKHItPnJsZW4gPj0gbikgeworCQkJCQkJci0+cmxlbiA9IG47CisJCQkJCQltZW1j cHkoci0+cnBhcmFtLCBjcywgci0+cmxlbik7CisJCQkJCX0KKworCQkJCQlyZXR1cm4gKDApOwor CQkJCX0KKwkJCX0KKwkJCWJyZWFrOworCisJCWRlZmF1bHQ6CisJCQlpZiAoZS0+ZXZlbnQgPT0g ci0+ZXZlbnQpIHsKKwkJCQlpZiAoci0+cmxlbiA+PSBuKSB7CisJCQkJCXItPnJsZW4gPSBuOwor CQkJCQltZW1jcHkoci0+cnBhcmFtLCBlICsgMSwgci0+cmxlbik7CisJCQkJfQorCisJCQkJcmV0 dXJuICgwKTsKKwkJCX0KKwkJCWJyZWFrOworCQl9CisJfSB3aGlsZSAodG8gPiAwKTsKKworCWVy cm5vID0gRVRJTUVET1VUOworCisJcmV0dXJuICgtMSk7Cit9CisKK2ludAorYnRfZGV2ZmlsdGVy KGludCBzLCBzdHJ1Y3QgYnRfZGV2ZmlsdGVyIGNvbnN0ICpuZXcsIHN0cnVjdCBidF9kZXZmaWx0 ZXIgKm9sZCkKK3sKKwlzdHJ1Y3QgbmdfYnRzb2NrZXRfaGNpX3Jhd19maWx0ZXIJZjsKKwlzb2Nr bGVuX3QJCQkJbGVuOworCWludAkJCQkJYml0OworCisJaWYgKG5ldyA9PSBOVUxMICYmIG9sZCA9 PSBOVUxMKSB7CisJCWVycm5vID0gRUlOVkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlpZiAo b2xkICE9IE5VTEwpIHsKKwkJbGVuID0gc2l6ZW9mKGYpOworCQlpZiAoZ2V0c29ja29wdChzLCBT T0xfSENJX1JBVywgU09fSENJX1JBV19GSUxURVIsICZmLCAmbGVuKSA8IDApCisJCQlyZXR1cm4g KC0xKTsKKworCQltZW1zZXQob2xkLCAwLCBzaXplb2YoKm9sZCkpOworCisJCWZvciAoYml0ID0g MDsgYml0IDwgTkdfSENJX0VWRU5UX1BLVDsgYml0ICsrKQorCQkJaWYgKGJpdF90ZXN0KGYucGFj a2V0X21hc2ssIGJpdCkpCisJCQkJb2xkLT5wYWNrZXRfbWFzayB8PSAoMSA8PCBiaXQpOworCisJ CWZvciAoYml0ID0gMDsgYml0IDwgTkdfSENJX0VWRU5UX01BU0tfU0laRSAqIDg7IGJpdCArKykK KwkJCWlmIChiaXRfdGVzdChmLmV2ZW50X21hc2ssIGJpdCkpCisJCQkJb2xkLT5ldmVudF9tYXNr IHw9ICgxIDw8IGJpdCk7CisJfQorCisJaWYgKG5ldyAhPSBOVUxMKSB7CisJCW1lbXNldCgmZiwg MCwgc2l6ZW9mKGYpKTsKKworCQlmb3IgKGJpdCA9IDA7IGJpdCA8IE5HX0hDSV9FVkVOVF9QS1Q7 IGJpdCArKykKKwkJCWlmIChuZXctPnBhY2tldF9tYXNrICYgKDEgPDwgYml0KSkKKwkJCQliaXRf c2V0KGYucGFja2V0X21hc2ssIGJpdCk7CisKKwkJZm9yIChiaXQgPSAwOyBiaXQgPCAoTkdfSENJ X0VWRU5UX01BU0tfU0laRSAqIDgpOyBiaXQgKyspCisJCQlpZiAobmV3LT5ldmVudF9tYXNrICYg KDEgPDwgYml0KSkKKwkJCQliaXRfc2V0KGYuZXZlbnRfbWFzaywgYml0KTsKKworCQlsZW4gPSBz aXplb2YoZik7CisJCWlmIChzZXRzb2Nrb3B0KHMsIFNPTF9IQ0lfUkFXLCBTT19IQ0lfUkFXX0ZJ TFRFUiwgJmYsIGxlbikgPCAwKQorCQkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuICgwKTsK K30KKworaW50CitidF9kZXZpbnF1aXJ5KGNoYXIgY29uc3QgKmRldm5hbWUsIGludCBsZW5ndGgs IGludCBudW1fcnNwLAorCQl1aW50OF90IGNvbnN0ICpsYXAsIHN0cnVjdCBidF9kZXZpbnF1aXJ5 ICoqaWkpCit7CisJdWludDhfdAkJCQlidWZbMzIwXTsKKwljaGFyCQkJCV9kZXZuYW1lW0hDSV9E RVZOQU1FX1NJWkVdOworCXN0cnVjdCBidF9kZXZmaWx0ZXIJCWY7CisJbmdfaGNpX2lucXVpcnlf Y3AJCSpjcCA9IChuZ19oY2lfaW5xdWlyeV9jcCAqKSBidWY7CisJbmdfaGNpX2V2ZW50X3BrdF90 CQkqZSA9IChuZ19oY2lfZXZlbnRfcGt0X3QgKikgYnVmOworCW5nX2hjaV9pbnF1aXJ5X3Jlc3Vs dF9lcAkqZXAgPSAobmdfaGNpX2lucXVpcnlfcmVzdWx0X2VwICopKGUrMSk7CisJbmdfaGNpX2lu cXVpcnlfcmVzcG9uc2UJCSppcjsKKwlzdHJ1Y3QgYnRfZGV2aW5xdWlyeQkJKmk7CisJaW50CQkJ CXMsIG47CisJdGltZV90CQkJCXRvOworCisJaWYgKGlpID09IE5VTEwpIHsKKwkJZXJybm8gPSBF SU5WQUw7CisJCXJldHVybiAoLTEpOworCX0KKworCWlmIChkZXZuYW1lID09IE5VTEwpIHsKKwkJ bWVtc2V0KF9kZXZuYW1lLCAwLCBzaXplb2YoX2Rldm5hbWUpKTsKKwkJZGV2bmFtZSA9IF9kZXZu YW1lOworCisJCW4gPSBidF9kZXZlbnVtKGJ0X2RldmFueV9jYiwgX2Rldm5hbWUpOworCQlpZiAo biA8PSAwKSB7CisJCQlpZiAobiA9PSAwKQorCQkJCSppaSA9IE5VTEw7CisKKwkJCXJldHVybiAo bik7CisJCX0KKwl9CisKKwlzID0gYnRfZGV2b3BlbihkZXZuYW1lKTsKKwlpZiAocyA8IDApCisJ CXJldHVybiAoLTEpOworCisJaWYgKGJ0X2RldmZpbHRlcihzLCBOVUxMLCAmZikgPCAwKSB7CisJ CWJ0X2RldmNsb3NlKHMpOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlmLmV2ZW50X21hc2sgfD0g KDEgPDwgKE5HX0hDSV9FVkVOVF9JTlFVSVJZX0NPTVBMIC0gMSkpOworCWYuZXZlbnRfbWFzayB8 PSAoMSA8PCAoTkdfSENJX0VWRU5UX0lOUVVJUllfUkVTVUxUIC0gMSkpOworCisJaWYgKGJ0X2Rl dmZpbHRlcihzLCAmZiwgTlVMTCkgPCAwKSB7CisJCWJ0X2RldmNsb3NlKHMpOworCQlyZXR1cm4g KC0xKTsKKwl9CisKKwlpZiAobGFwID09IE5VTEwpIHsKKwkJY3AtPmxhcFswXSA9IDB4MzM7CisJ CWNwLT5sYXBbMV0gPSAweDhiOworCQljcC0+bGFwWzJdID0gMHg5ZTsKKwl9IGVsc2UgeworCQlj cC0+bGFwWzBdID0gbGFwWzBdOworCQljcC0+bGFwWzFdID0gbGFwWzFdOworCQljcC0+bGFwWzJd ID0gbGFwWzJdOworCX0KKworCWlmIChsZW5ndGggPD0gMCB8fCBsZW5ndGggPiAyNTUpCisJCWxl bmd0aCA9IDQ7CS8qIDUuMTIgc2Vjb25kcyAqLworCWNwLT5pbnF1aXJ5X2xlbmd0aCA9ICh1aW50 OF90KSBsZW5ndGg7CisKKwl0byA9ICh0aW1lX3QpKChkb3VibGUpIGxlbmd0aCAqIDEuMjgpICsg MTsKKworCWlmIChudW1fcnNwIDw9IDAgfHwgbnVtX3JzcCA+IDI1NSkKKwkJbnVtX3JzcCA9IDg7 CisJY3AtPm51bV9yZXNwb25zZXMgPSAodWludDhfdCkgbnVtX3JzcDsKKworCWkgPSAqaWkgPSBj YWxsb2MobnVtX3JzcCwgc2l6ZW9mKHN0cnVjdCBidF9kZXZpbnF1aXJ5KSk7CisJaWYgKGkgPT0g TlVMTCkgeworCQlidF9kZXZjbG9zZShzKTsKKwkJZXJybm8gPSBFTk9NRU07CisJCXJldHVybiAo LTEpOworCX0KKworCWlmIChidF9kZXZzZW5kKHMsIE5HX0hDSV9PR0ZfTElOS19DT05UUk9MLCBO R19IQ0lfT0NGX0lOUVVJUlksCisJCQlzaXplb2YoKmNwKSwgY3ApIDwgMCkgeworCQlmcmVlKGkp OworCQlidF9kZXZjbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCit3YWl0X2Zvcl9tb3Jl OgorCisJbiA9IGJ0X2RldnJlY3YocywgYnVmLCBzaXplb2YoYnVmKSwgdG8pOworCWlmIChuIDwg MCkgeworCQlmcmVlKGkpOworCQlidF9kZXZjbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQor CisJaWYgKG4gPCBzaXplb2YobmdfaGNpX2V2ZW50X3BrdF90KSkgeworCQlmcmVlKGkpOworCQli dF9kZXZjbG9zZShzKTsKKwkJZXJybm8gPSBFSU87CisJCXJldHVybiAoLTEpOworCX0KKworCXN3 aXRjaCAoZS0+ZXZlbnQpIHsKKwljYXNlIE5HX0hDSV9FVkVOVF9JTlFVSVJZX0NPTVBMOgorCQli cmVhazsKKworCWNhc2UgTkdfSENJX0VWRU5UX0lOUVVJUllfUkVTVUxUOgorCQlpciA9IChuZ19o Y2lfaW5xdWlyeV9yZXNwb25zZSAqKShlcCArIDEpOworCisjdW5kZWYJTUlOCisjZGVmaW5lCU1J TihhLCBiKQkoKChhKSA8IChiKSk/IChhKSA6IChiKSkKKworCQlmb3IgKG4gPSAwOyBuIDwgTUlO KGVwLT5udW1fcmVzcG9uc2VzLCBudW1fcnNwKTsgbiArKykgeworCQkJYmRhZGRyX2NvcHkoJmkt PmJkYWRkciwgJmlyLT5iZGFkZHIpOworCQkJaS0+cHNjYW5fcmVwX21vZGUgPSBpci0+cGFnZV9z Y2FuX3JlcF9tb2RlOworCQkJaS0+cHNjYW5fcGVyaW9kX21vZGUgPSBpci0+cGFnZV9zY2FuX3Bl cmlvZF9tb2RlOworCQkJaS0+cHNjYW5fbW9kZSA9IGlyLT5wYWdlX3NjYW5fbW9kZTsKKwkJCW1l bWNweShpLT5kZXZfY2xhc3MsIGlyLT51Y2xhc3MsIHNpemVvZihpLT5kZXZfY2xhc3MpKTsKKwkJ CWktPmNsb2NrX29mZnNldCA9IGxlMTZ0b2goaXItPmNsb2NrX29mZnNldCk7CisKKwkJCWlyICsr OworCQkJaSArKzsKKwkJCW51bV9yc3AgLS07CisJCX0KKwkJLyogRkFMTFRIUk9VR0ggKi8KKwor CWRlZmF1bHQ6CisJCWdvdG8gd2FpdF9mb3JfbW9yZTsKKwkJLyogTk9UIFJFQUNIRUQgKi8KKwl9 CisKKwlidF9kZXZjbG9zZShzKTsKKwkJCisJcmV0dXJuIChpIC0gKmlpKTsKK30KKworaW50CiBi dF9kZXZpbmZvKHN0cnVjdCBidF9kZXZpbmZvICpkaSkKIHsKIAl1bmlvbiB7CkBAIC01Myw2ICs0 NTksNyBAQAogCQlzdHJ1Y3QgbmdfYnRzb2NrZXRfaGNpX3Jhd19ub2RlX2RlYnVnCQlyODsKIAl9 CQkJCQkJcnA7CiAJc3RydWN0IHNvY2thZGRyX2hjaQkJCQloYTsKKwlzb2NrbGVuX3QJCQkJCWhh bGVuOwogCWludAkJCQkJCXMsIHJ2YWw7CiAKIAlpZiAoZGkgPT0gTlVMTCkgewpAQCAtNjAsMjcg KzQ2NywxNCBAQAogCQlyZXR1cm4gKC0xKTsKIAl9CiAKLQltZW1zZXQoJmhhLCAwLCBzaXplb2Yo aGEpKTsKLQloYS5oY2lfbGVuID0gc2l6ZW9mKGhhKTsKLQloYS5oY2lfZmFtaWx5ID0gQUZfQkxV RVRPT1RIOwotCi0JaWYgKGJ0X2F0b24oZGktPmRldm5hbWUsICZycC5yMS5iZGFkZHIpKSB7Ci0J CWlmICghYnRfZGV2bmFtZShoYS5oY2lfbm9kZSwgJnJwLnIxLmJkYWRkcikpCi0JCQlyZXR1cm4g KC0xKTsKLQl9IGVsc2UgaWYgKGJ0X2RldjJub2RlKGRpLT5kZXZuYW1lLCBoYS5oY2lfbm9kZSwK LQkJCQkJc2l6ZW9mKGhhLmhjaV9ub2RlKSkgPT0gTlVMTCkgewotCQllcnJubyA9IEVOWElPOwot CQlyZXR1cm4gKC0xKTsKLQl9Ci0KLQlzID0gc29ja2V0KFBGX0JMVUVUT09USCwgU09DS19SQVcs IEJMVUVUT09USF9QUk9UT19IQ0kpOworCXMgPSBidF9kZXZvcGVuKGRpLT5kZXZuYW1lKTsKIAlp ZiAocyA8IDApCiAJCXJldHVybiAoLTEpOwogCiAJcnZhbCA9IC0xOwogCi0JaWYgKGJpbmQocywg KHN0cnVjdCBzb2NrYWRkciAqKSAmaGEsIHNpemVvZihoYSkpIDwgMCB8fAotCSAgICBjb25uZWN0 KHMsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJmhhLCBzaXplb2YoaGEpKSA8IDApCisJaGFsZW4gPSBz aXplb2YoaGEpOworCWlmIChnZXRzb2NrbmFtZShzLCAoc3RydWN0IHNvY2thZGRyICopICZoYSwg JmhhbGVuKSA8IDApCiAJCWdvdG8gYmFkOwogCXN0cmxjcHkoZGktPmRldm5hbWUsIGhhLmhjaV9u b2RlLCBzaXplb2YoZGktPmRldm5hbWUpKTsKIApAQCAtMTM4LDcgKzUzMiw3IEBACiAKIAlydmFs ID0gMDsKIGJhZDoKLQljbG9zZShzKTsKKwlidF9kZXZjbG9zZShzKTsKIAogCXJldHVybiAocnZh bCk7CiB9CkBAIC0yMDUsNiArNTk5LDEzIEBACiAJcmV0dXJuIChjb3VudCk7CiB9CiAKK3N0YXRp YyBpbnQKK2J0X2RldmFueV9jYihpbnQgcywgc3RydWN0IGJ0X2RldmluZm8gY29uc3QgKmRpLCB2 b2lkICp4ZGV2bmFtZSkKK3sKKwlzdHJsY3B5KChjaGFyICopIHhkZXZuYW1lLCBkaS0+ZGV2bmFt ZSwgSENJX0RFVk5BTUVfU0laRSk7CisJcmV0dXJuICgxKTsKK30KKwogc3RhdGljIGNoYXIgKgog YnRfZGV2Mm5vZGUoY2hhciBjb25zdCAqZGV2bmFtZSwgY2hhciAqbm9kZW5hbWUsIGludCBubmxl bikKIHsKSW5kZXg6IGJsdWV0b290aC4zCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGJsdWV0b290aC4zCShyZXZp c2lvbiAxOTA4NzApCisrKyBibHVldG9vdGguMwkod29ya2luZyBjb3B5KQpAQCAtMjUsNyArMjUs NyBAQAogLlwiICRJZDogYmx1ZXRvb3RoLjMsdiAxLjUgMjAwMy8wNS8yMCAyMzowNDozMCBtYXgg RXhwICQKIC5cIiAkRnJlZUJTRCQKIC5cIgotLkRkIEZlYnJ1YXJ5IDEzLCAyMDA5CisuRGQgQXBy aWwgOSwgMjAwOQogLkR0IEJMVUVUT09USCAzCiAuT3MKIC5TaCBOQU1FCkBAIC00MSw2ICs0MSwx NyBAQAogLk5tIGJ0X2VuZHByb3RvZW50ICwKIC5ObSBidF9hdG9uICwKIC5ObSBidF9udG9hICwK Ky5ObSBidF9kZXZhZGRyICwKKy5ObSBidF9kZXZuYW1lICwKKy5ObSBidF9kZXZpbmZvICwKKy5O bSBidF9kZXZlbnVtICwKKy5ObSBidF9kZXZvcGVuICwKKy5ObSBidF9kZXZjbG9zZSAsCisuTm0g YnRfZGV2c2VuZCAsCisuTm0gYnRfZGV2cmVjdiAsCisuTm0gYnRfZGV2cmVxICwKKy5ObSBidF9k ZXZmaWx0ZXIgLAorLk5tIGJ0X2RldmlucXVpcnkgLAogLk5tIGJkYWRkcl9zYW1lICwKIC5ObSBi ZGFkZHJfYW55ICwKIC5ObSBiZGFkZHJfY29weQpAQCAtODQsNiArOTUsMjAgQEAKIC5GdCBpbnQK IC5GbiBidF9kZXZlbnVtICJidF9kZXZlbnVtX2NiX3QgKmNiIiAidm9pZCAqYXJnIgogLkZ0IGlu dAorLkZuIGJ0X2Rldm9wZW4gImNoYXIgY29uc3QgKmRldm5hbWUiCisuRnQgaW50CisuRm4gYnRf ZGV2Y2xvc2UgImludCBzIgorLkZ0IGludAorLkZuIGJ0X2RldnNlbmQgImludCBzIiAidWludDE2 X3Qgb2dmIiAidWludDE2X3Qgb2NmIiAiaW50IHBsZW4iICJ2b2lkICpwYXJhbSIKKy5GdCBpbnQK Ky5GbiBidF9kZXZyZWN2ICJpbnQgcyIgInVpbnQ4X3QgKmJ1ZiIgImludCBzaXplIiAidGltZV90 IHRvIgorLkZ0IGludAorLkZuIGJ0X2RldnJlcSAiaW50IHMiICJzdHJ1Y3QgYnRfZGV2cmVxICpy IiAidGltZV90IHRvIgorLkZ0IGludAorLkZuIGJ0X2RldmZpbHRlciAiaW50IHMiICJzdHJ1Y3Qg YnRfZGV2ZmlsdGVyIGNvbnN0ICpuZXciICJzdHJ1Y3QgYnRfZGV2ZmlsdGVyICpvbGQiCisuRnQg aW50CisuRm4gYnRfZGV2aW5xdWlyeSAiY2hhciBjb25zdCAqZGV2bmFtZSIgImludCBsZW5ndGgi ICJpbnQgbnVtX3JzcCIgInVpbnQ4X3QgY29uc3QgKmxhcCIgInN0cnVjdCBidF9kZXZpbnF1aXJ5 ICoqaWkiCisuRnQgaW50CiAuRm4gYmRhZGRyX3NhbWUgImNvbnN0IGJkYWRkcl90ICphIiAiY29u c3QgYmRhZGRyX3QgKmIiCiAuRnQgaW50CiAuRm4gYmRhZGRyX2FueSAiY29uc3QgYmRhZGRyX3Qg KmEiCkBAIC0zMTEsNiArMzM2LDIxOSBAQAogb3IgLTEgaWYgYW4gZXJyb3Igb2NjdXJyZWQuCiAu UHAKIFRoZQorLkZuIGJ0X2Rldm9wZW4KK2Z1bmN0aW9uIG9wZW5zIEJsdWV0b290aCBkZXZpY2Ug d2l0aCB0aGUgZ2l2ZW4KKy5GYSBkZXZuYW1lCithbmQgcmV0dXJucyBjb25uZWN0ZWQgYW5kIGJv dW5kCisuRHYgSENJCitzb2NrZXQuCitUaGUgZnVuY3Rpb24gcmV0dXJucyAtMSBpZiBhbiBlcnJv ciBoYXMgb2NjdXJyZWQuCisuUHAKK1RoZQorLkZuIGJ0X2RldmNsb3NlCitjbG9zZXMgcGFzc2Vk CisuRHYgSENJCitzb2NrZXQKKy5GYSBzICwKK3ByZXZpb3VzbHkgb2J0YWluZWQgd2l0aAorLlhy IGJ0X2Rldm9wZW4gMyAuCisuUHAKK1RoZQorLkZuIGJ0X2RldnNlbmQKK2Z1bmN0aW9uIHNlbmRz IEJsdWV0b290aAorLkR2IEhDSQorY29tbWFuZCB3aXRoIHRoZSBPcENvZGUgR3JvdXAgRmllbGQK Ky5GYSBvZ2YKK2FuZAorT3BDb2RlIENvbW1hbmQgRmllbGQKKy5GYSBvY2YKK3RvIHRoZSBwcm92 aWRlZCBzb2NrZXQKKy5GYSBzICwKK3ByZXZpb3VzbHkgb2J0YWluZWQgd2l0aAorLlhyIGJ0X2Rl dm9wZW4gMyAuCitUaGUKKy5GYSBwbGVuCithbmQKKy5GYSBwYXJhbQorcGFyYW1ldGVycyBzcGVj aWZ5IGNvbW1hbmQgcGFyYW1ldGVycy4KK1RoZSBmdW5jdGlvbiByZXR1cm5zIDAgb24gc3VjY2Vz cywKK29yIC0xIGlmIGFuIGVycm9yIG9jY3VycmVkLgorLlBwCitUaGUKKy5GbiBidF9kZXZyZWN2 CitmdW5jdGlvbiByZWNlaXZlcyBvbmUgQmx1ZXRvb3RoCisuRHYgSENJCitldmVudCBwYWNrZXQg ZnJvbSB0aGUgc29ja2V0CisuRmEgcyAsCitwcmV2aW91c2x5IG9idGFpbmVkIHdpdGgKKy5YciBi dF9kZXZvcGVuIDMgLgorVGhlIGV2ZW50IHBhY2tldCBpcyBwbGFjZWQgaW50byB0aGUgcHJvdmlk ZWQgYnVmZmVyCisuRmEgYnVmCitvZiBzaXplCisuRmEgc2l6ZSAuCitUaGUKKy5GYSB0bworcGFy YW1ldGVyIHNwZWNpZmllcyByZWNlaXZlIHRpbWVvdXQgaW4gc2Vjb25kcy4KK1RoZSBmdW5jdGlv biByZXR1cm5zIHRvdGFsIG51bWJlciBvZiBieXRlcyByZWNldmllZCwKK29yIC0xIGlmIGFuIGVy cm9yIG9jY3VycmVkLgorLlBwCitUaGUKKy5GbiBidF9kZXZyZXEKK2Z1bmN0aW9uIG1ha2VzIEJs dWV0b290aAorLkR2IEhDSQorcmVxdWVzdCB0byB0aGUgc29ja2V0CisuRmEgcyAsCitwcmV2aW91 c2x5IG9idGFpbmVkIHdpdGgKKy5YciBidF9kZXZvcGVuIDMgLgorVGhlIGZ1bmN0aW9uIHdpbGwg c2VuZCB0aGUgc3BlY2lmaWVkIGNvbW1hbmQgYW5kIHdpbGwgd2FpdCBmb3IgdGhlIHNwZWNpZmll ZAorZXZlbnQsCitvciB0aW1lb3V0CisuRmEgdG8KK3NlY29uZHMgdG8gb2NjdXIuCitUaGUKKy5W dCBidF9kZXZyZXEKK3N0cnVjdHVyZSBpcyBkZWZpbmVkIGFzIGZvbGxvd3MKKy5CZCAtbGl0ZXJh bCAtb2Zmc2V0IGluZGVudAorc3RydWN0IGJ0X2RldnJlcQoreworICAgICAgICB1aW50MTZfdCAg ICAgICAgb2dmOworICAgICAgICB1aW50MTZfdCAgICAgICAgb2NmOworICAgICAgICBpbnQgICAg ICAgICAgICAgZXZlbnQ7CisgICAgICAgIHZvaWQgICAgICAgICAgICAqY3BhcmFtOworICAgICAg ICBpbnQgICAgICAgICAgICAgY2xlbjsKKyAgICAgICAgdm9pZCAgICAgICAgICAgICpycGFyYW07 CisgICAgICAgIGludCAgICAgICAgICAgICBybGVuOworfTsKKy5FZAorLlBwCitUaGUKKy5GYSBv Z2YKK2FuZAorLkZhIG9jZgorZmllbGRzIHNwZWNpZnkgT3BDb2RlIEdyb3VwIGFuZCBDb21tYW5k IEZpZWxkIHJlc3BlY3RpdmVseS4KK1RoZQorLkZhIGNwYXJhbQorYW5kCisuRmEgY2xlbgorZmll bGRzIHNwZWNpZnkgY29tbWFuZCBwYXJhbWV0ZXJzIGRhdGEgYW5kIGNvbW1hbmQgcGFyYW1ldGVy cyBkYXRhIHNpemUKK3Jlc3BlY3RpdmVseS4KK1RoZQorLkZhIGV2ZW50CitmaWVsZCBzcGVjaWZp ZXMgd2hpY2ggQmx1ZXRvb3RoCisuRHYgSENJCitldmVudCBJRCB0aGUgZnVuY3Rpb24gc2hvdWxk IHdhaXQgZm9yLgorVGhlCisuRmEgcnBhcmFtCithbmQKKy5GYSBybGVuCitwYXJhbWV0ZXJzIHNw ZWNpZnkgYnVmZmVyIGFuZCBidWZmZXIgc2l6ZSByZXNwZWN0aXZlbHkgd2hlcmUgcmV0dXJuCitw YXJhbWV0ZXJzIHNob3VsZCBiZSBwbGFjZWQuCitUaGUgZnVuY3Rpb24gcmV0dXJucyAwIG9uIHN1 Y2Nlc3MsIG9yIC0xIGlmIGFuIGVycm9yIG9jY3VycmVkLgorLlBwCitUaGUKKy5GbiBidF9kZXZm aWx0ZXIKK2NvbnRyb2xzIHRoZSBsb2NhbAorLkR2IEhDSQorZmlsdGVyIGFzc29jaWF0ZWQgd2l0 aCB0aGUgc29ja2V0CisuRmEgcyAsCitwcmV2aW91c2x5IG9idGFpbmVkIHdpdGgKKy5YciBidF9k ZXZvcGVuIDMgLgorRmlsdGVyaW5nIGNhbiBiZSBkb25lIG9uIHBhY2tldCB0eXBlcywgaS5lLgor LkR2IEFDTCAsCisuRHYgU0NPIG9yCisuRHYgSENJCitldmVudCBwYWNrZXRzLCBhbmQsIGluIGFk ZGl0aW9uLCBvbgorLkR2IEhDSQorZXZlbnQgSURzLgorQmVmb3JlIGFwcGx5aW5nCisuRmEgbmV3 CitmaWx0ZXIgKGlmIHByb3ZpZGVkKSB0aGUgZnVuY3Rpb24gd2lsbCB0cnkgdG8gb2J0YWluIGN1 cnJlbnQgZmlsdGVyCitmcm9tIHRoZSBzb2NrZXQKKy5GYSBzCithbmQgcGxhY2UgaXQgaW50byB0 aGUKKy5GYSBvbGQKK3BhcmFtZXRlciAoaWYgcHJvdmlkZWQpLgorVGhlCisuVnQgYnRfZGV2Zmls dGVyCitzdHJ1Y3R1cmUgaXMgZGVmaW5lZCBhcyBmb2xsb3dzCisuQmQgLWxpdGVyYWwgLW9mZnNl dCBpbmRlbnQKK3N0cnVjdCBidF9kZXZmaWx0ZXIgeworICAgICAgICB1aW50NjRfdCAgICAgICAg ZXZlbnRfbWFzazsKKyAgICAgICAgdWludDhfdCAgICAgICAgIHBhY2tldF9tYXNrOworfTsKKy5F ZAorLlBwCitCb3RoCisuRmEgZXZlbnRfbWFzaworYW5kCisuRmEgcGFja2V0X21hc2sKK2ZpZWxk cyBhcmUgYml0IG1hc2tzLgorSWYgYSBiaXQKKy5GYSBOCitpcyBjbGVhcmVkIGluIHRoZQorLkZh IGV2ZW50X21hc2sKK3RoZW4gdGhlIGNvcnJlc3BvbmRpbmcgQmx1ZXRvb3RoCisuRHYgSENJCitl dmVudCBJRAorLkZhIE4KK2lzIGZpbHRlcmVkIG91dC4KK0lmIGEgYml0CisuRmEgTgoraXMgY2xl YXJlZCBpbiB0aGUKKy5GYSBwYWNrZXRfbWFzawordGhlbiBhbGwgdGhlIHBhY2tldHMgd2l0aCB0 aGUgY29ycmVzcG9uZGluZyBwYWNrZXQgaW5kaWNhdG9yIGFyZSBmaWx0ZXJlZCBvdXQuCitUaGUg ZnVuY3Rpb24gcmV0dXJucyAwIG9uIHN1Y2Nlc3MsIG9yIC0xIGlmIGFuIGVycm9yIG9jY3VycmVk LgorLlBwCitUaGUKKy5GbiBidF9kZXZpbnF1aXJ5CitmdW5jdGlvbiBwZXJmb3JtcyBCbHVldG9v dGggaW5xdWlyeS4KK1RoZQorLkZhIGRldm5hbWUKK3BhcmFtZXRlciBzcGVjaWZpZXMgd2hpY2gg bG9jYWwgQmx1ZXRvb3RoIGRldmljZSBzaG91bGQgcGVyZm9ybSBhbiBpbnF1aXJ5LgorSWYgbm90 IHNlY2lmaWVkLCBpLmUuCisuRHYgTlVMTCAsCit0aGVuIGZpcnN0IGF2YWlsYWJsZSBkZXZpY2Ug d2lsbCBiZSB1c2VkLgorVGhlCisuRmEgbGVuZ3RoCitwYXJhbWV0ZXJzIHNwZWNpZmllcyB0aGUg dG90YWwgbGVuZ3RoIG9mIGFuIGlucXVpcnkgaW4gMS4yOCBzZWNvbmQgdW5pdHMuCitJZiBub3Qg c3BlY2lmaWVkLCBpLmUuIDAsIGRlZmF1bHQgdmFsdWUgd2lsbCBiZSB1c2VkLgorVGhlCisuRmEg bnVtX3JzcAorcGFyYW1ldGVyIHNwZWNpZmllcyB0aGUgbnVtYmVyIG9mIHJlc3BvbnNlcyB0aGF0 IGNhbiBiZSByZWNlaXZlZCBiZWZvcmUKK3RoZSBpbnF1aXJ5IGlzIGhhbHRlZC4KK0lmIG5vdCBz cGVjaWZpZWQsIGkuZS4gMCwgZGVmYXVsdCB2YWx1ZSB3aWxsIGJlIHVzZWQuCitUaGUKKy5GYSBs YXAKK3BhcmFtZXRlciBjb250YWlucyB0aGUgTEFQIGZyb20gd2hpY2ggdGhlIGlucXVpcnkgYWNj ZXNzIGNvZGUgd2lsbCBiZQorYmUgZGVyaXZlZCB3aGVuIHRoZSBpbnF1aXJ5IHByb2NlZHVyZSBp cyBtYWRlLgorSWYgbm90IHNwZWNpZmllZCwgaS5lLgorLkR2IE5VTEwgLAordGhlbiBHSUFDIExB UCA5ZTo4YjozMyB3aWxsIGJlIHVzZWQuCitUaGUKKy5GYSBpaQorcGFyYW1ldGVyIHNwZWNpZmll cyB3aGVyZSB0byBwbGFjZSBpbnF1aXJ5IHJlc3VsdHMuCitPbiBzdWNjZXNzLCB0aGUgZnVuY3Rp b24gd2lsbCByZXR1cm4gdG90YWwgbnVtYmVyIG9mIGlucXVpcnkgcmVzdWx0cywKK3dpbGwgYWxs b2NhdGUgYnVmZmVyIHRvIHN0b3JlIGFsbCB0aGUgaW5xdWlyeSByZXN1bHRzIGFuZAord2lsbCBy ZXR1cm4gcG9pbnRlciB0byB0aGUgYWxsb2NhdGVkIGJ1ZmZlciBpbiB0aGUKKy5GYSBpaQorcGFy YW1ldGVyLgorSXQgaXMgdXAgdG8gdGhlIGNhbGxlciBvZiB0aGUgZnVuY3Rpb24gdG8gZGlzcG9z ZSBvZiB0aGUgYnVmZmVyLgorVGhlIGZ1bmN0aW9uIHJldHVybnMgLTEgaWYgYW4gZXJyb3IgaGFz IG9jY3VycmVkLgorVGhlCisuVnQgYnRfZGV2aW5xdWlyeQorc3RydWN0dXJlIGlzIGRlZmluZWQg YXMgZm9sbG93cworLkJkIC1saXRlcmFsIC1vZmZzZXQgaW5kZW50CitzdHJ1Y3QgYnRfZGV2aW5x dWlyeSB7CisgICAgICAgIGJkYWRkcl90ICAgICAgICBiZGFkZHI7CisgICAgICAgIHVpbnQ4X3Qg ICAgICAgICBwc2Nhbl9yZXBfbW9kZTsKKyAgICAgICAgdWludDhfdCAgICAgICAgIHBzY2FuX3Bl cmlvZF9tb2RlOworICAgICAgICB1aW50OF90ICAgICAgICAgcHNjYW5fbW9kZTsKKyAgICAgICAg dWludDhfdCAgICAgICAgIGRldl9jbGFzc1szXTsKKyAgICAgICAgdWludDE2X3QgICAgICAgIGNs b2NrX29mZnNldDsKK307CisuRWQKKy5QcAorVGhlCiAuRm4gYmRhZGRyX3NhbWUgLAogLkZuIGJk YWRkcl9hbnkKIGFuZApJbmRleDogYmx1ZXRvb3RoLmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYmx1ZXRvb3Ro LmgJKHJldmlzaW9uIDE5MDg3MCkKKysrIGJsdWV0b290aC5oCSh3b3JraW5nIGNvcHkpCkBAIC0z OSw2ICszOSw3IEBACiAjaW5jbHVkZSA8c3lzL2VuZGlhbi5oPgogI2luY2x1ZGUgPHN5cy9pb2N0 bC5oPgogI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxzeXMvdWlvLmg+CiAjaW5j bHVkZSA8c3lzL3VuLmg+CiAjaW5jbHVkZSA8ZXJybm8uaD4KICNpbmNsdWRlIDxuZXRkYi5oPgpA QCAtNDYsNiArNDcsNyBAQAogI2luY2x1ZGUgPG5ldGdyYXBoL2JsdWV0b290aC9pbmNsdWRlL25n X2hjaS5oPgogI2luY2x1ZGUgPG5ldGdyYXBoL2JsdWV0b290aC9pbmNsdWRlL25nX2wyY2FwLmg+ CiAjaW5jbHVkZSA8bmV0Z3JhcGgvYmx1ZXRvb3RoL2luY2x1ZGUvbmdfYnRzb2NrZXQuaD4KKyNp bmNsdWRlIDx0aW1lLmg+CiAKIF9fQkVHSU5fREVDTFMKIApAQCAtMTI5LDggKzEzMSw0MiBAQAog CXVpbnQ4X3QJCV9wYWRkaW5nWzIwXTsJLyogbGVhdmUgc3BhY2UgZm9yIGZ1dHVyZSBhZGRpdGlv bnMgKi8KIH07CiAKK3N0cnVjdCBidF9kZXZyZXEKK3sKKwl1aW50MTZfdAlvZ2Y7CisJdWludDE2 X3QJb2NmOworCWludAkJZXZlbnQ7CisJdm9pZAkJKmNwYXJhbTsKKwlpbnQJCWNsZW47CisJdm9p ZAkJKnJwYXJhbTsKKwlpbnQJCXJsZW47Cit9OworCitzdHJ1Y3QgYnRfZGV2ZmlsdGVyIHsKKwl1 aW50NjRfdAlldmVudF9tYXNrOworCXVpbnQ4X3QJCXBhY2tldF9tYXNrOworfTsKKworc3RydWN0 IGJ0X2RldmlucXVpcnkgeworCWJkYWRkcl90CWJkYWRkcjsKKwl1aW50OF90CQlwc2Nhbl9yZXBf bW9kZTsKKwl1aW50OF90CQlwc2Nhbl9wZXJpb2RfbW9kZTsKKwl1aW50OF90CQlwc2Nhbl9tb2Rl OworCXVpbnQ4X3QJCWRldl9jbGFzc1szXTsKKwl1aW50MTZfdAljbG9ja19vZmZzZXQ7Cit9Owor CiB0eXBlZGVmIGludAkoYnRfZGV2ZW51bV9jYl90KShpbnQsIHN0cnVjdCBidF9kZXZpbmZvIGNv bnN0ICosIHZvaWQgKik7CiAKK2ludAkJYnRfZGV2b3BlbiAoY2hhciBjb25zdCAqZGV2bmFtZSk7 CitpbnQJCWJ0X2RldmNsb3NlKGludCBzKTsKK2ludAkJYnRfZGV2c2VuZCAoaW50IHMsIHVpbnQx Nl90IG9nZiwgdWludDE2X3Qgb2NmLCBpbnQgcGxlbiwgdm9pZCAqcGFyYW0pOworaW50CQlidF9k ZXZyZWN2IChpbnQgcywgdWludDhfdCAqYnVmLCBpbnQgc2l6ZSwgdGltZV90IHRvKTsKK2ludAkJ YnRfZGV2cmVxICAoaW50IHMsIHN0cnVjdCBidF9kZXZyZXEgKnIsIHRpbWVfdCB0byk7CitpbnQJ CWJ0X2RldmZpbHRlcihpbnQgcywgc3RydWN0IGJ0X2RldmZpbHRlciBjb25zdCAqbmV3LAorCQkJ ICAgICBzdHJ1Y3QgYnRfZGV2ZmlsdGVyICpvbGQpOworaW50CQlidF9kZXZpbnF1aXJ5KGNoYXIg Y29uc3QgKmRldm5hbWUsIGludCBsZW5ndGgsIGludCBudW1fcnNwLAorCQkJICAgICAgdWludDhf dCBjb25zdCAqbGFwLCBzdHJ1Y3QgYnRfZGV2aW5xdWlyeSAqKmlpKTsKIGludAkJYnRfZGV2aW5m byAoc3RydWN0IGJ0X2RldmluZm8gKmRpKTsKIGludAkJYnRfZGV2ZW51bSAoYnRfZGV2ZW51bV9j Yl90ICpjYiwgdm9pZCAqYXJnKTsKIApJbmRleDogTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTWFr ZWZpbGUJKHJldmlzaW9uIDE5MDg3MCkKKysrIE1ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0z Myw2ICszMywxMyBAQAogTUxJTktTKz0JYmx1ZXRvb3RoLjMgYnRfZGV2aW5mby4zCiBNTElOS1Mr PQlibHVldG9vdGguMyBidF9kZXZlbnVtLjMKIAorTUxJTktTKz0JYmx1ZXRvb3RoLjMgYnRfZGV2 b3Blbi4zCitNTElOS1MrPQlibHVldG9vdGguMyBidF9kZXZjbG9zZS4zCitNTElOS1MrPQlibHVl dG9vdGguMyBidF9kZXZzZW5kLjMKK01MSU5LUys9CWJsdWV0b290aC4zIGJ0X2RldnJlcS4zCitN TElOS1MrPQlibHVldG9vdGguMyBidF9kZXZmaWx0ZXIuMworTUxJTktTKz0JYmx1ZXRvb3RoLjMg YnRfZGV2aW5xdWlyeS4zCisKIE1MSU5LUys9CWJsdWV0b290aC4zIGJkYWRkcl9zYW1lLjMKIE1M SU5LUys9CWJsdWV0b290aC4zIGJkYWRkcl9hbnkuMwogTUxJTktTKz0JYmx1ZXRvb3RoLjMgYmRh ZGRyX2NvcHkuMwo= --00163630f1d78efeb804679e39d2-- From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 16 08:47:27 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E79481065676 for ; Thu, 16 Apr 2009 08:47:27 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 813938FC08 for ; Thu, 16 Apr 2009 08:47:27 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1LuNFi-0008R2-Qz; Thu, 16 Apr 2009 09:47:22 +0100 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32235-09; Thu, 16 Apr 2009 09:47:22 +0100 (BST) Received: from [10.215.89.122] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1LuNFf-0008Qy-CB; Thu, 16 Apr 2009 09:47:22 +0100 Received: (nullmailer pid 354 invoked by uid 1000); Thu, 16 Apr 2009 08:46:09 -0000 Date: Thu, 16 Apr 2009 09:46:09 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4E2F.2000805@incunabulum.net> <49DE6D42.6000004@incunabulum.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1239871569.560012.1086.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:47:28 -0000 On Wed, 15 Apr 2009, Maksim Yevmenkin wrote: > please find attached patch that implements more compatibility shims. > any comments are greatly appreciated. +int +bt_devsend(int s, uint16_t ogf, uint16_t ocf, int plen, void *param) One thing that I did when writing the NetBSD stack which IMHO made source somewhat cleaner was provide HCI_CMD_xxxx definintions that included the OGF and OCF directly, eg #define HCI_OGF_LINK_CONTROL 0x01 #define HCI_OCF_INQUIRY 0x0001 #define HCI_CMD_INQUIRY 0x0401 It could be considered a remote possibility of a namespace conflict (ie same command in different groups) but I doubt that it will ever happen (and would be easily handled). That would make this into +int +bt_devsend(int s, uint16_t cmd, int plen, void *param) thoughts? Also, plen should be a size_t and it should come after the pointer, see write, read, memcpy, snprintf etc for prior art :) +int +bt_devrecv(int s, uint8_t *buf, int size, time_t to) and ditto for size_t here +int +bt_devinquiry(char const *devname, int length, int num_rsp, + uint8_t const *lap, struct bt_devinquiry **ii) I wonder if allowing for a different LAP is at all useful? I would say, for the very remote possibility that somebody wants to do that, they could just cut and past the code.. Also with inquiry, would it make sense to just pass a time_t and calculate the 'inquiry length' internally? +struct bt_devinquiry { + bdaddr_t bdaddr; + uint8_t pscan_rep_mode; + uint8_t pscan_period_mode; + uint8_t pscan_mode; + uint8_t dev_class[3]; + uint16_t clock_offset; +}; Does this structure need to be a direct copy of the inquiry result? page_scan_period_mode and page_scan_mode are deprecated since a long time so its probably not worth providing the values (most devices return 0 that I've seen). We also need to [be able] to handle the inquiry-result-with-rssi which gives an extra int8_t RSSI value, and the 2.1 extended inquiry result data. For both of those, I think its ok if they are zero if not provided. (ie actual support can be added later) struct bt_devinquiry { bdaddr_t bdaddr; uint8_t pscan_rep_mode; uint8_t class[HCI_CLASS_SIZE]; uint16_t clock_offset; int8_t rssi; uint8_t data[HCI_EXTENDED_INQUIRY_DATA_SIZE]; }; ? +int +bt_devfilter(int s, struct bt_devfilter const *new, struct bt_devfilter *old) And finally, the HCI filter is slightly different in NetBSD (I provided independent PKT and EVT filters each of 256 bits) and I'm going to think about that.. regards, iain From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 16 12:16:34 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5610B106564A for ; Thu, 16 Apr 2009 12:16:34 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id E138B8FC0C for ; Thu, 16 Apr 2009 12:16:33 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1LuQW8-0003Fm-95; Thu, 16 Apr 2009 13:16:32 +0100 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12338-08; Thu, 16 Apr 2009 13:16:31 +0100 (BST) Received: from [10.215.89.122] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1LuQW5-0003FM-BH; Thu, 16 Apr 2009 13:16:31 +0100 Received: (nullmailer pid 1260 invoked by uid 1000); Thu, 16 Apr 2009 12:15:18 -0000 Date: Thu, 16 Apr 2009 13:15:18 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <1239871569.560012.1086.nullmailer@galant.ukfsn.org> References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4E2F.2000805@incunabulum.net> <49DE6D42.6000004@incunabulum.net> <1239871569.560012.1086.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1239884118.412855.3144.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 12:16:34 -0000 On Thu, 16 Apr 2009, Iain Hibbert wrote: > +int > +bt_devfilter(int s, struct bt_devfilter const *new, struct bt_devfilter *old) > > And finally, the HCI filter is slightly different in NetBSD (I provided > independent PKT and EVT filters each of 256 bits) and I'm going to think > about that.. Ok, I'm not objecting in priniciple to coupling the two filters together but I think that bt_devfilter should be opaque enough that the API does not depend about its internal structure. Ie, requiring the caller to subtract 1 and manage the bitwise manipulation + f.event_mask |= (1 << (NG_HCI_EVENT_INQUIRY_COMPL - 1)); + f.event_mask |= (1 << (NG_HCI_EVENT_INQUIRY_RESULT - 1)); is too specific and makes the callers somewhat messy. Can we provide some kind of accessor functions to do that? I include below what I used in NetBSD for an example.. Also, at least for events, the full 256 bits is required because there are events such as 0xfe (BT Logo) and 0xff (Vendor) that may currently be returned and the highest value (in 2.1 spec) is 0x3d, dangerously close to the 64 bit limit. Although its not likely that there will be many packet types added, it could be that some manufacturers would introduce custom packet types with similarly high end values.. (eg for private device configuration?) regards, iain /* * HCI socket filter and get/set routines * * for ease of use, we filter 256 possible events/packets */ struct hci_filter { uint32_t mask[8]; /* 256 bits */ }; static __inline void hci_filter_set(uint8_t bit, struct hci_filter *filter) { uint8_t off = bit - 1; off >>= 5; filter->mask[off] |= (1 << ((bit - 1) & 0x1f)); } static __inline void hci_filter_clr(uint8_t bit, struct hci_filter *filter) { uint8_t off = bit - 1; off >>= 5; filter->mask[off] &= ~(1 << ((bit - 1) & 0x1f)); } static __inline int hci_filter_test(uint8_t bit, struct hci_filter *filter) { uint8_t off = bit - 1; off >>= 5; return (filter->mask[off] & (1 << ((bit - 1) & 0x1f))); } From owner-freebsd-bluetooth@FreeBSD.ORG Fri Apr 17 23:21:27 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 805741065670 for ; Fri, 17 Apr 2009 23:21:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 29C168FC0A for ; Fri, 17 Apr 2009 23:21:26 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so152299yxg.57 for ; Fri, 17 Apr 2009 16:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3NH6J5MsUSlg9cIugJ1EEDkLEg+vQZvlO7a8fDaXDC0=; b=asRm+gY3oWJ5TV7C3DkB7Twjv9VGyTYTBuGyiB7htypR+Ex4HPXj8MW7fHPfqGMlMh NrZqJfHuv/WJosQAoNaLexOEIuSSFc30Qf93WIRGh/rqDlIEKxWwih/oeL1/SwQJoYKx cPlw3EQ3ZiBil9Hnl2ndpkC9EjGLUpmSoLutg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=S2F6S2zzPVNT7/w47xFxJfdDJXhIqpGDZdlm28vmbSNN4irm+yRFeElV6F2h2xeQ/L Bvvu/2t/laF3oHxojOTHdmUUfIqJChgjR2C1hSn4vXxqHp4gq2ou0R1ykolcMiO1EKfr j+QQ98pIOJRdO5gJFKioRifFTWugNwSy3/lds= MIME-Version: 1.0 Received: by 10.90.113.11 with SMTP id l11mr3769930agc.87.1240010486543; Fri, 17 Apr 2009 16:21:26 -0700 (PDT) In-Reply-To: <1239884118.412855.3144.nullmailer@galant.ukfsn.org> References: <49D92E26.2030508@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4E2F.2000805@incunabulum.net> <49DE6D42.6000004@incunabulum.net> <1239871569.560012.1086.nullmailer@galant.ukfsn.org> <1239884118.412855.3144.nullmailer@galant.ukfsn.org> Date: Fri, 17 Apr 2009 16:21:26 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: multipart/mixed; boundary=0016361e86c09175d40467c870d7 Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 23:21:27 -0000 --0016361e86c09175d40467c870d7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Apr 16, 2009 at 5:15 AM, Iain Hibbert wrote: > On Thu, 16 Apr 2009, Iain Hibbert wrote: > >> +int >> +bt_devfilter(int s, struct bt_devfilter const *new, struct bt_devfilter *old) >> >> And finally, the HCI filter is slightly different in NetBSD (I provided >> independent PKT and EVT filters each of 256 bits) and I'm going to think >> about that.. > > Ok, I'm not objecting in priniciple to coupling the two filters together > but I think that bt_devfilter should be opaque enough that the API does > not depend about its internal structure. Ie, requiring the caller to > subtract 1 and manage the bitwise manipulation > > + f.event_mask |= (1 << (NG_HCI_EVENT_INQUIRY_COMPL - 1)); > + f.event_mask |= (1 << (NG_HCI_EVENT_INQUIRY_RESULT - 1)); > > is too specific and makes the callers somewhat messy. Can we provide some > kind of accessor functions to do that? I include below what I used in > NetBSD for an example.. > > Also, at least for events, the full 256 bits is required because there are > events such as 0xfe (BT Logo) and 0xff (Vendor) that may currently be > returned and the highest value (in 2.1 spec) is 0x3d, dangerously close to > the 64 bit limit. Although its not likely that there will be many packet > types added, it could be that some manufacturers would introduce custom > packet types with similarly high end values.. (eg for private device > configuration?) thanks for the feedback. i'm attaching revisited patch. please take a look and let me know if this is something you happy with. thanks, max --0016361e86c09175d40467c870d7 Content-Type: text/plain; charset=US-ASCII; name="bluetooth.hci.diff.txt" Content-Disposition: attachment; filename="bluetooth.hci.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ftni7vzx0 SW5kZXg6IGhjaS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGhjaS5jCShyZXZpc2lvbiAxOTEwMTIpCisrKyBo Y2kuYwkod29ya2luZyBjb3B5KQpAQCAtMzAsMTUgKzMwLDQ0NSBAQAogICogJEZyZWVCU0QkCiAg Ki8KIAorI2luY2x1ZGUgPGFzc2VydC5oPgogI2luY2x1ZGUgPGJsdWV0b290aC5oPgogI2luY2x1 ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAj aW5jbHVkZSA8dW5pc3RkLmg+CiAKK3N0YXRpYyBpbnQgICAgYnRfZGV2YW55X2NiKGludCBzLCBz dHJ1Y3QgYnRfZGV2aW5mbyBjb25zdCAqZGksIHZvaWQgKnhkZXZuYW1lKTsKIHN0YXRpYyBjaGFy ICogYnRfZGV2Mm5vZGUgKGNoYXIgY29uc3QgKmRldm5hbWUsIGNoYXIgKm5vZGVuYW1lLCBpbnQg bm5sZW4pOwogCiBpbnQKK2J0X2Rldm9wZW4oY2hhciBjb25zdCAqZGV2bmFtZSkKK3sKKwlzdHJ1 Y3Qgc29ja2FkZHJfaGNpCWhhOworCWJkYWRkcl90CQliYTsKKwlpbnQJCQlzOworCisJaWYgKGRl dm5hbWUgPT0gTlVMTCkgeworCQllcnJubyA9IEVJTlZBTDsKKwkJcmV0dXJuICgtMSk7CisJfQor CisJbWVtc2V0KCZoYSwgMCwgc2l6ZW9mKGhhKSk7CisJaGEuaGNpX2xlbiA9IHNpemVvZihoYSk7 CisJaGEuaGNpX2ZhbWlseSA9IEFGX0JMVUVUT09USDsKKworCWlmIChidF9hdG9uKGRldm5hbWUs ICZiYSkpIHsKKwkJaWYgKCFidF9kZXZuYW1lKGhhLmhjaV9ub2RlLCAmYmEpKQorCQkJcmV0dXJu ICgtMSk7CisJfSBlbHNlIGlmIChidF9kZXYybm9kZShkZXZuYW1lLCBoYS5oY2lfbm9kZSwKKwkJ CQkJc2l6ZW9mKGhhLmhjaV9ub2RlKSkgPT0gTlVMTCkgeworCQllcnJubyA9IEVOWElPOworCQly ZXR1cm4gKC0xKTsKKwl9CisKKwlzID0gc29ja2V0KFBGX0JMVUVUT09USCwgU09DS19SQVcsIEJM VUVUT09USF9QUk9UT19IQ0kpOworCWlmIChzIDwgMCkKKwkJcmV0dXJuICgtMSk7CisKKwlpZiAo YmluZChzLCAoc3RydWN0IHNvY2thZGRyICopICZoYSwgc2l6ZW9mKGhhKSkgPCAwIHx8CisJICAg IGNvbm5lY3QocywgKHN0cnVjdCBzb2NrYWRkciAqKSAmaGEsIHNpemVvZihoYSkpIDwgMCkgewor CQljbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuIChzKTsKK30KKworaW50 CitidF9kZXZjbG9zZShpbnQgcykKK3sKKwlyZXR1cm4gKGNsb3NlKHMpKTsKK30KKworaW50Citi dF9kZXZzZW5kKGludCBzLCB1aW50MTZfdCBvcGNvZGUsIHZvaWQgKnBhcmFtLCBzaXplX3QgcGxl bikKK3sKKwluZ19oY2lfY21kX3BrdF90CWg7CisJc3RydWN0IGlvdmVjCQlpdlsyXTsKKwlpbnQJ CQlpdm47CisKKwlpZiAocGxlbiA8IDAgfHwgKHBsZW4gPiAwICYmIHBhcmFtID09IE5VTEwpKSB7 IAorCQllcnJubyA9IEVJTlZBTDsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJaXZbMF0uaW92X2Jh c2UgPSAmaDsKKwlpdlswXS5pb3ZfbGVuID0gc2l6ZW9mKGgpOworCWl2biA9IDE7CisKKwloLnR5 cGUgPSBOR19IQ0lfQ01EX1BLVDsKKwloLm9wY29kZSA9IGh0b2xlMTYob3Bjb2RlKTsKKwlpZiAo cGxlbiA+IDApIHsKKwkJaC5sZW5ndGggPSBwbGVuOworCisJCWl2WzFdLmlvdl9iYXNlID0gcGFy YW07CisJCWl2WzFdLmlvdl9sZW4gPSBwbGVuOworCQlpdm4gPSAyOworCX0gZWxzZQorCQloLmxl bmd0aCA9IDA7CisKKwl3aGlsZSAod3JpdGV2KHMsIGl2LCBpdm4pIDwgMCkgeworCQlpZiAoZXJy bm8gPT0gRUFHQUlOIHx8IGVycm5vID09IEVJTlRSKQorCQkJY29udGludWU7CisKKwkJcmV0dXJu ICgtMSk7CisJfQorCisJcmV0dXJuICgwKTsKK30KKworaW50CitidF9kZXZyZWN2KGludCBzLCB1 aW50OF90ICpidWYsIHNpemVfdCBzaXplLCB0aW1lX3QgdG8pCit7CisJZmRfc2V0CQlyZmQ7CisJ c3RydWN0IHRpbWV2YWwJdHY7CisJaW50CQluOworCisJaWYgKGJ1ZiA9PSBOVUxMIHx8IHNpemUg PD0gMCB8fCB0byA8IDApIHsKKwkJZXJybm8gPSBFSU5WQUw7CisJCXJldHVybiAoLTEpOworCX0K KworCUZEX1pFUk8oJnJmZCk7CisJRkRfU0VUKHMsICZyZmQpOworCisJdHYudHZfc2VjID0gdG87 CisJdHYudHZfdXNlYyA9IDA7CisKKwl3aGlsZSAoKG4gPSBzZWxlY3QocyArIDEsICZyZmQsIE5V TEwsIE5VTEwsICZ0dikpIDwgMCkgeworCQlpZiAoZXJybm8gPT0gRUFHQUlOIHx8IGVycm5vID09 IEVJTlRSKQorCQkJY29udGludWU7CisKKwkJcmV0dXJuICgtMSk7CisJfQorCisJaWYgKG4gPT0g MCkgeworCQllcnJubyA9IEVUSU1FRE9VVDsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJYXNzZXJ0 KEZEX0lTU0VUKHMsICZyZmQpKTsKKworCXdoaWxlICgobiA9IHJlYWQocywgYnVmLCBzaXplKSkg PCAwKSB7CisJCWlmIChlcnJubyA9PSBFQUdBSU4gfHwgZXJybm8gPT0gRUlOVFIpCisJCQljb250 aW51ZTsKKworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlyZXR1cm4gKG4pOworfQorCitpbnQKK2J0 X2RldnJlcShpbnQgcywgc3RydWN0IGJ0X2RldnJlcSAqciwgdGltZV90IHRvKQoreworCXVpbnQ4 X3QJCQkJYnVmWzMyMF07IC8qIG1vcmUgdGhhbiBlbm91Z2ggKi8KKwluZ19oY2lfZXZlbnRfcGt0 X3QJCSplID0gKG5nX2hjaV9ldmVudF9wa3RfdCAqKSBidWY7CisJbmdfaGNpX2NvbW1hbmRfY29t cGxfZXAJCSpjYyA9IChuZ19oY2lfY29tbWFuZF9jb21wbF9lcCAqKShlKzEpOworCW5nX2hjaV9j b21tYW5kX3N0YXR1c19lcAkqY3MgPSAobmdfaGNpX2NvbW1hbmRfc3RhdHVzX2VwKikoZSsxKTsK Kwl0aW1lX3QJCQkJdF9lbmQ7CisJdWludDE2X3QJCQlvcGNvZGU7CisJaW50CQkJCW47CisKKwlp ZiAocyA8IDAgfHwgciA9PSBOVUxMIHx8IHRvIDwgMCkgeworCQllcnJubyA9IEVJTlZBTDsKKwkJ cmV0dXJuICgtMSk7CisJfQorCisJaWYgKHItPnJsZW4gPCAwIHx8IChyLT5ybGVuID4gMCAmJiBy LT5ycGFyYW0gPT0gTlVMTCkpIHsKKwkJZXJybm8gPSBFSU5WQUw7CisJCXJldHVybiAoLTEpOwor CX0KKworCW4gPSBidF9kZXZzZW5kKHMsIHItPm9wY29kZSwgci0+Y3BhcmFtLCByLT5jbGVuKTsK KwlpZiAobiA8IDApCisJCXJldHVybiAoLTEpOworCisJb3Bjb2RlID0gaHRvbGUxNihyLT5vcGNv ZGUpOworCXRfZW5kID0gdGltZShOVUxMKSArIHRvOworCisJZG8geworCQl0byA9IHRfZW5kIC0g dGltZShOVUxMKTsKKwkJaWYgKHRvIDwgMCkKKwkJCXRvID0gMDsKKworCQluID0gYnRfZGV2cmVj dihzLCBidWYsIHNpemVvZihidWYpLCB0byk7CisJCWlmIChuIDwgMCkKKwkJCXJldHVybiAoLTEp OworCisJCWlmIChuIDwgc2l6ZW9mKCplKSkgeworCQkJZXJybm8gPSBFTVNHU0laRTsKKwkJCXJl dHVybiAoLTEpOworCQl9CisKKwkJaWYgKGUtPnR5cGUgIT0gTkdfSENJX0VWRU5UX1BLVCkgewor CQkJZXJybm8gPSBFSU87CisJCQlyZXR1cm4gKC0xKTsKKwkJfQorCisJCW4gLT0gc2l6ZW9mKCpl KTsKKworCQlzd2l0Y2ggKGUtPmV2ZW50KSB7CisJCWNhc2UgTkdfSENJX0VWRU5UX0NPTU1BTkRf Q09NUEw6CisJCQlpZiAoY2MtPm9wY29kZSA9PSBvcGNvZGUpIHsKKwkJCQluIC09IHNpemVvZigq Y2MpOworCisJCQkJaWYgKHItPnJsZW4gPj0gbikgeworCQkJCQlyLT5ybGVuID0gbjsKKwkJCQkJ bWVtY3B5KHItPnJwYXJhbSwgY2MgKyAxLCByLT5ybGVuKTsKKwkJCQl9CisKKwkJCQlyZXR1cm4g KDApOworCQkJfQorCQkJYnJlYWs7CisKKwkJY2FzZSBOR19IQ0lfRVZFTlRfQ09NTUFORF9TVEFU VVM6CisJCQlpZiAoY3MtPm9wY29kZSA9PSBvcGNvZGUpIHsKKwkJCQlpZiAoci0+ZXZlbnQgIT0g TkdfSENJX0VWRU5UX0NPTU1BTkRfU1RBVFVTKSB7CisJCQkJCWlmIChjcy0+c3RhdHVzICE9IDAp IHsKKwkJCQkJCWVycm5vID0gRUlPOworCQkJCQkJcmV0dXJuICgtMSk7CisJCQkJCX0KKwkJCQl9 IGVsc2UgeworCQkJCQlpZiAoci0+cmxlbiA+PSBuKSB7CisJCQkJCQlyLT5ybGVuID0gbjsKKwkJ CQkJCW1lbWNweShyLT5ycGFyYW0sIGNzLCByLT5ybGVuKTsKKwkJCQkJfQorCisJCQkJCXJldHVy biAoMCk7CisJCQkJfQorCQkJfQorCQkJYnJlYWs7CisKKwkJZGVmYXVsdDoKKwkJCWlmIChlLT5l dmVudCA9PSByLT5ldmVudCkgeworCQkJCWlmIChyLT5ybGVuID49IG4pIHsKKwkJCQkJci0+cmxl biA9IG47CisJCQkJCW1lbWNweShyLT5ycGFyYW0sIGUgKyAxLCByLT5ybGVuKTsKKwkJCQl9CisK KwkJCQlyZXR1cm4gKDApOworCQkJfQorCQkJYnJlYWs7CisJCX0KKwl9IHdoaWxlICh0byA+IDAp OworCisJZXJybm8gPSBFVElNRURPVVQ7CisKKwlyZXR1cm4gKC0xKTsKK30KKworaW50CitidF9k ZXZmaWx0ZXIoaW50IHMsIHN0cnVjdCBidF9kZXZmaWx0ZXIgY29uc3QgKm5ldywgc3RydWN0IGJ0 X2RldmZpbHRlciAqb2xkKQoreworCXN0cnVjdCBuZ19idHNvY2tldF9oY2lfcmF3X2ZpbHRlcglm OworCXNvY2tsZW5fdAkJCQlsZW47CisKKwlpZiAobmV3ID09IE5VTEwgJiYgb2xkID09IE5VTEwp IHsKKwkJZXJybm8gPSBFSU5WQUw7CisJCXJldHVybiAoLTEpOworCX0KKworCWlmIChvbGQgIT0g TlVMTCkgeworCQlsZW4gPSBzaXplb2YoZik7CisJCWlmIChnZXRzb2Nrb3B0KHMsIFNPTF9IQ0lf UkFXLCBTT19IQ0lfUkFXX0ZJTFRFUiwgJmYsICZsZW4pIDwgMCkKKwkJCXJldHVybiAoLTEpOwor CisJCW1lbXNldChvbGQsIDAsIHNpemVvZigqb2xkKSk7CisJCW1lbWNweShvbGQtPnBhY2tldF9t YXNrLCAmZi5wYWNrZXRfbWFzaywKKwkJCXNpemVvZihvbGQtPnBhY2tldF9tYXNrKSk7CisJCW1l bWNweShvbGQtPmV2ZW50X21hc2ssICZmLmV2ZW50X21hc2ssCisJCQlzaXplb2Yob2xkLT5ldmVu dF9tYXNrKSk7CisJfQorCisJaWYgKG5ldyAhPSBOVUxMKSB7CisJCW1lbXNldCgmZiwgMCwgc2l6 ZW9mKGYpKTsKKwkJbWVtY3B5KCZmLnBhY2tldF9tYXNrLCBuZXctPnBhY2tldF9tYXNrLCBzaXpl b2YoZi5wYWNrZXRfbWFzaykpOworCQltZW1jcHkoJmYuZXZlbnRfbWFzaywgbmV3LT5ldmVudF9t YXNrLCBzaXplb2YoZi5ldmVudF9tYXNrKSk7CisKKwkJbGVuID0gc2l6ZW9mKGYpOworCQlpZiAo c2V0c29ja29wdChzLCBTT0xfSENJX1JBVywgU09fSENJX1JBV19GSUxURVIsICZmLCBsZW4pIDwg MCkKKwkJCXJldHVybiAoLTEpOworCX0KKworCXJldHVybiAoMCk7Cit9CisKK3ZvaWQKK2J0X2Rl dmZpbHRlcl9wa3Rfc2V0KHN0cnVjdCBidF9kZXZmaWx0ZXIgKmZpbHRlciwgaW50IHR5cGUpCit7 CisJYml0X3NldChmaWx0ZXItPnBhY2tldF9tYXNrLCB0eXBlIC0gMSk7Cit9CisKK3ZvaWQKK2J0 X2RldmZpbHRlcl9wa3RfY2xyKHN0cnVjdCBidF9kZXZmaWx0ZXIgKmZpbHRlciwgaW50IHR5cGUp Cit7CisJYml0X2NsZWFyKGZpbHRlci0+cGFja2V0X21hc2ssIHR5cGUgLSAxKTsKK30KKworaW50 CitidF9kZXZmaWx0ZXJfcGt0X3RzdChzdHJ1Y3QgYnRfZGV2ZmlsdGVyIGNvbnN0ICpmaWx0ZXIs IGludCB0eXBlKQoreworCXJldHVybiAoYml0X3Rlc3QoZmlsdGVyLT5wYWNrZXRfbWFzaywgdHlw ZSAtIDEpKTsKK30KKwordm9pZAorYnRfZGV2ZmlsdGVyX2V2dF9zZXQoc3RydWN0IGJ0X2RldmZp bHRlciAqZmlsdGVyLCBpbnQgZXZlbnQpCit7CisJYml0X3NldChmaWx0ZXItPmV2ZW50X21hc2ss IGV2ZW50IC0gMSk7Cit9CisKK3ZvaWQKK2J0X2RldmZpbHRlcl9ldnRfY2xyKHN0cnVjdCBidF9k ZXZmaWx0ZXIgKmZpbHRlciwgaW50IGV2ZW50KQoreworCWJpdF9jbGVhcihmaWx0ZXItPmV2ZW50 X21hc2ssIGV2ZW50IC0gMSk7Cit9CisKK2ludAorYnRfZGV2ZmlsdGVyX2V2dF90c3Qoc3RydWN0 IGJ0X2RldmZpbHRlciBjb25zdCAqZmlsdGVyLCBpbnQgZXZlbnQpCit7CisJcmV0dXJuIChiaXRf dGVzdChmaWx0ZXItPmV2ZW50X21hc2ssIGV2ZW50IC0gMSkpOworfQorCitpbnQKK2J0X2Rldmlu cXVpcnkoY2hhciBjb25zdCAqZGV2bmFtZSwgdGltZV90IGxlbmd0aCwgaW50IG51bV9yc3AsCisJ CXN0cnVjdCBidF9kZXZpbnF1aXJ5ICoqaWkpCit7CisJdWludDhfdAkJCQlidWZbMzIwXTsKKwlj aGFyCQkJCV9kZXZuYW1lW0hDSV9ERVZOQU1FX1NJWkVdOworCXN0cnVjdCBidF9kZXZmaWx0ZXIJ CWY7CisJbmdfaGNpX2lucXVpcnlfY3AJCSpjcCA9IChuZ19oY2lfaW5xdWlyeV9jcCAqKSBidWY7 CisJbmdfaGNpX2V2ZW50X3BrdF90CQkqZSA9IChuZ19oY2lfZXZlbnRfcGt0X3QgKikgYnVmOwor CW5nX2hjaV9pbnF1aXJ5X3Jlc3VsdF9lcAkqZXAgPSAobmdfaGNpX2lucXVpcnlfcmVzdWx0X2Vw ICopKGUrMSk7CisJbmdfaGNpX2lucXVpcnlfcmVzcG9uc2UJCSppcjsKKwlzdHJ1Y3QgYnRfZGV2 aW5xdWlyeQkJKmk7CisJaW50CQkJCXMsIG47CisJdGltZV90CQkJCXRvOworCisJaWYgKGlpID09 IE5VTEwpIHsKKwkJZXJybm8gPSBFSU5WQUw7CisJCXJldHVybiAoLTEpOworCX0KKworCWlmIChk ZXZuYW1lID09IE5VTEwpIHsKKwkJbWVtc2V0KF9kZXZuYW1lLCAwLCBzaXplb2YoX2Rldm5hbWUp KTsKKwkJZGV2bmFtZSA9IF9kZXZuYW1lOworCisJCW4gPSBidF9kZXZlbnVtKGJ0X2RldmFueV9j YiwgX2Rldm5hbWUpOworCQlpZiAobiA8PSAwKSB7CisJCQlpZiAobiA9PSAwKQorCQkJCSppaSA9 IE5VTEw7CisKKwkJCXJldHVybiAobik7CisJCX0KKwl9CisKKwlzID0gYnRfZGV2b3BlbihkZXZu YW1lKTsKKwlpZiAocyA8IDApCisJCXJldHVybiAoLTEpOworCisJaWYgKGJ0X2RldmZpbHRlcihz LCBOVUxMLCAmZikgPCAwKSB7CisJCWJ0X2RldmNsb3NlKHMpOworCQlyZXR1cm4gKC0xKTsKKwl9 CisKKwlidF9kZXZmaWx0ZXJfZXZ0X3NldCgmZiwgTkdfSENJX0VWRU5UX0lOUVVJUllfQ09NUEwp OworCWJ0X2RldmZpbHRlcl9ldnRfc2V0KCZmLCBOR19IQ0lfRVZFTlRfSU5RVUlSWV9SRVNVTFQp OworCisJaWYgKGJ0X2RldmZpbHRlcihzLCAmZiwgTlVMTCkgPCAwKSB7CisJCWJ0X2RldmNsb3Nl KHMpOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwkvKiBBbHdheXMgdXNlIEdJQUMgTEFQICovCisJ Y3AtPmxhcFswXSA9IDB4MzM7CisJY3AtPmxhcFsxXSA9IDB4OGI7CisJY3AtPmxhcFsyXSA9IDB4 OWU7CisKKwkvKiBDYWxjdWxhdGUgaW5xdWlyZSBsZW5ndGggaW4gMS4yOCBzZWNvbmQgdW5pdHMg Ki8KKwl0byA9ICh0aW1lX3QpICgoZG91YmxlKSBsZW5ndGggLyAxLjI4KTsKKwlpZiAodG8gPD0g MCkKKwkJY3AtPmlucXVpcnlfbGVuZ3RoID0gNDsJCS8qIDUuMTIgc2Vjb25kcyAqLworCWVsc2Ug aWYgKHRvID4gMjU0KQorCQljcC0+aW5xdWlyeV9sZW5ndGggPSAyNTU7CS8qIDMyNi40MCBzZWNv bmRzICovCisJZWxzZQorCQljcC0+aW5xdWlyeV9sZW5ndGggPSB0byArIDE7CisKKwl0byA9ICh0 aW1lX3QpKChkb3VibGUpIGNwLT5pbnF1aXJ5X2xlbmd0aCAqIDEuMjgpICsgMTsKKworCWlmIChu dW1fcnNwIDw9IDAgfHwgbnVtX3JzcCA+IDI1NSkKKwkJbnVtX3JzcCA9IDg7CisJY3AtPm51bV9y ZXNwb25zZXMgPSAodWludDhfdCkgbnVtX3JzcDsKKworCWkgPSAqaWkgPSBjYWxsb2MobnVtX3Jz cCwgc2l6ZW9mKHN0cnVjdCBidF9kZXZpbnF1aXJ5KSk7CisJaWYgKGkgPT0gTlVMTCkgeworCQli dF9kZXZjbG9zZShzKTsKKwkJZXJybm8gPSBFTk9NRU07CisJCXJldHVybiAoLTEpOworCX0KKwor CWlmIChidF9kZXZzZW5kKHMsCisJCU5HX0hDSV9PUENPREUoTkdfSENJX09HRl9MSU5LX0NPTlRS T0wsIE5HX0hDSV9PQ0ZfSU5RVUlSWSksCisJCQljcCwgc2l6ZW9mKCpjcCkpIDwgMCkgeworCQlm cmVlKGkpOworCQlidF9kZXZjbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCit3YWl0X2Zv cl9tb3JlOgorCisJbiA9IGJ0X2RldnJlY3YocywgYnVmLCBzaXplb2YoYnVmKSwgdG8pOworCWlm IChuIDwgMCkgeworCQlmcmVlKGkpOworCQlidF9kZXZjbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7 CisJfQorCisJaWYgKG4gPCBzaXplb2YobmdfaGNpX2V2ZW50X3BrdF90KSkgeworCQlmcmVlKGkp OworCQlidF9kZXZjbG9zZShzKTsKKwkJZXJybm8gPSBFSU87CisJCXJldHVybiAoLTEpOworCX0K KworCXN3aXRjaCAoZS0+ZXZlbnQpIHsKKwljYXNlIE5HX0hDSV9FVkVOVF9JTlFVSVJZX0NPTVBM OgorCQlicmVhazsKKworCWNhc2UgTkdfSENJX0VWRU5UX0lOUVVJUllfUkVTVUxUOgorCQlpciA9 IChuZ19oY2lfaW5xdWlyeV9yZXNwb25zZSAqKShlcCArIDEpOworCisjdW5kZWYJTUlOCisjZGVm aW5lCU1JTihhLCBiKQkoKChhKSA8IChiKSk/IChhKSA6IChiKSkKKworCQlmb3IgKG4gPSAwOyBu IDwgTUlOKGVwLT5udW1fcmVzcG9uc2VzLCBudW1fcnNwKTsgbiArKykgeworCQkJYmRhZGRyX2Nv cHkoJmktPmJkYWRkciwgJmlyLT5iZGFkZHIpOworCQkJaS0+cHNjYW5fcmVwX21vZGUgPSBpci0+ cGFnZV9zY2FuX3JlcF9tb2RlOworCQkJaS0+cHNjYW5fcGVyaW9kX21vZGUgPSBpci0+cGFnZV9z Y2FuX3BlcmlvZF9tb2RlOworCQkJbWVtY3B5KGktPmRldl9jbGFzcywgaXItPnVjbGFzcywgc2l6 ZW9mKGktPmRldl9jbGFzcykpOworCQkJaS0+Y2xvY2tfb2Zmc2V0ID0gbGUxNnRvaChpci0+Y2xv Y2tfb2Zmc2V0KTsKKworCQkJaXIgKys7CisJCQlpICsrOworCQkJbnVtX3JzcCAtLTsKKwkJfQor CQkvKiBGQUxMVEhST1VHSCAqLworCisJZGVmYXVsdDoKKwkJZ290byB3YWl0X2Zvcl9tb3JlOwor CQkvKiBOT1QgUkVBQ0hFRCAqLworCX0KKworCWJ0X2RldmNsb3NlKHMpOworCQkKKwlyZXR1cm4g KGkgLSAqaWkpOworfQorCitpbnQKIGJ0X2RldmluZm8oc3RydWN0IGJ0X2RldmluZm8gKmRpKQog ewogCXVuaW9uIHsKQEAgLTUzLDYgKzQ4Myw3IEBACiAJCXN0cnVjdCBuZ19idHNvY2tldF9oY2lf cmF3X25vZGVfZGVidWcJCXI4OwogCX0JCQkJCQlycDsKIAlzdHJ1Y3Qgc29ja2FkZHJfaGNpCQkJ CWhhOworCXNvY2tsZW5fdAkJCQkJaGFsZW47CiAJaW50CQkJCQkJcywgcnZhbDsKIAogCWlmIChk aSA9PSBOVUxMKSB7CkBAIC02MCwyNyArNDkxLDE0IEBACiAJCXJldHVybiAoLTEpOwogCX0KIAot CW1lbXNldCgmaGEsIDAsIHNpemVvZihoYSkpOwotCWhhLmhjaV9sZW4gPSBzaXplb2YoaGEpOwot CWhhLmhjaV9mYW1pbHkgPSBBRl9CTFVFVE9PVEg7Ci0KLQlpZiAoYnRfYXRvbihkaS0+ZGV2bmFt ZSwgJnJwLnIxLmJkYWRkcikpIHsKLQkJaWYgKCFidF9kZXZuYW1lKGhhLmhjaV9ub2RlLCAmcnAu cjEuYmRhZGRyKSkKLQkJCXJldHVybiAoLTEpOwotCX0gZWxzZSBpZiAoYnRfZGV2Mm5vZGUoZGkt PmRldm5hbWUsIGhhLmhjaV9ub2RlLAotCQkJCQlzaXplb2YoaGEuaGNpX25vZGUpKSA9PSBOVUxM KSB7Ci0JCWVycm5vID0gRU5YSU87Ci0JCXJldHVybiAoLTEpOwotCX0KLQotCXMgPSBzb2NrZXQo UEZfQkxVRVRPT1RILCBTT0NLX1JBVywgQkxVRVRPT1RIX1BST1RPX0hDSSk7CisJcyA9IGJ0X2Rl dm9wZW4oZGktPmRldm5hbWUpOwogCWlmIChzIDwgMCkKIAkJcmV0dXJuICgtMSk7CiAKIAlydmFs ID0gLTE7CiAKLQlpZiAoYmluZChzLCAoc3RydWN0IHNvY2thZGRyICopICZoYSwgc2l6ZW9mKGhh KSkgPCAwIHx8Ci0JICAgIGNvbm5lY3QocywgKHN0cnVjdCBzb2NrYWRkciAqKSAmaGEsIHNpemVv ZihoYSkpIDwgMCkKKwloYWxlbiA9IHNpemVvZihoYSk7CisJaWYgKGdldHNvY2tuYW1lKHMsIChz dHJ1Y3Qgc29ja2FkZHIgKikgJmhhLCAmaGFsZW4pIDwgMCkKIAkJZ290byBiYWQ7CiAJc3RybGNw eShkaS0+ZGV2bmFtZSwgaGEuaGNpX25vZGUsIHNpemVvZihkaS0+ZGV2bmFtZSkpOwogCkBAIC0x MzgsNyArNTU2LDcgQEAKIAogCXJ2YWwgPSAwOwogYmFkOgotCWNsb3NlKHMpOworCWJ0X2RldmNs b3NlKHMpOwogCiAJcmV0dXJuIChydmFsKTsKIH0KQEAgLTIwNSw2ICs2MjMsMTMgQEAKIAlyZXR1 cm4gKGNvdW50KTsKIH0KIAorc3RhdGljIGludAorYnRfZGV2YW55X2NiKGludCBzLCBzdHJ1Y3Qg YnRfZGV2aW5mbyBjb25zdCAqZGksIHZvaWQgKnhkZXZuYW1lKQoreworCXN0cmxjcHkoKGNoYXIg KikgeGRldm5hbWUsIGRpLT5kZXZuYW1lLCBIQ0lfREVWTkFNRV9TSVpFKTsKKwlyZXR1cm4gKDEp OworfQorCiBzdGF0aWMgY2hhciAqCiBidF9kZXYybm9kZShjaGFyIGNvbnN0ICpkZXZuYW1lLCBj aGFyICpub2RlbmFtZSwgaW50IG5ubGVuKQogewpJbmRleDogYmx1ZXRvb3RoLjMKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gYmx1ZXRvb3RoLjMJKHJldmlzaW9uIDE5MTAxMikKKysrIGJsdWV0b290aC4zCSh3b3Jr aW5nIGNvcHkpCkBAIC0yNSw3ICsyNSw3IEBACiAuXCIgJElkOiBibHVldG9vdGguMyx2IDEuNSAy MDAzLzA1LzIwIDIzOjA0OjMwIG1heCBFeHAgJAogLlwiICRGcmVlQlNEJAogLlwiCi0uRGQgRmVi cnVhcnkgMTMsIDIwMDkKKy5EZCBBcHJpbCA5LCAyMDA5CiAuRHQgQkxVRVRPT1RIIDMKIC5Pcwog LlNoIE5BTUUKQEAgLTQxLDYgKzQxLDIzIEBACiAuTm0gYnRfZW5kcHJvdG9lbnQgLAogLk5tIGJ0 X2F0b24gLAogLk5tIGJ0X250b2EgLAorLk5tIGJ0X2RldmFkZHIgLAorLk5tIGJ0X2Rldm5hbWUg LAorLk5tIGJ0X2RldmluZm8gLAorLk5tIGJ0X2RldmVudW0gLAorLk5tIGJ0X2Rldm9wZW4gLAor Lk5tIGJ0X2RldmNsb3NlICwKKy5ObSBidF9kZXZzZW5kICwKKy5ObSBidF9kZXZyZWN2ICwKKy5O bSBidF9kZXZyZXEgLAorLk5tIGJ0X2RldmZpbHRlciAsCisuTm0gYnRfZGV2ZmlsdGVyX3BrdF9z ZXQgLAorLk5tIGJ0X2RldmZpbHRlcl9wa3RfY2xyICwKKy5ObSBidF9kZXZmaWx0ZXJfcGt0X3Rz dCAsCisuTm0gYnRfZGV2ZmlsdGVyX2V2dF9zZXQgLAorLk5tIGJ0X2RldmZpbHRlcl9ldnRfY2xy ICwKKy5ObSBidF9kZXZmaWx0ZXJfZXZ0X3RzdCAsCisuTm0gYnRfZGV2aW5xdWlyeSAsCiAuTm0g YmRhZGRyX3NhbWUgLAogLk5tIGJkYWRkcl9hbnkgLAogLk5tIGJkYWRkcl9jb3B5CkBAIC04NCw2 ICsxMDEsMzIgQEAKIC5GdCBpbnQKIC5GbiBidF9kZXZlbnVtICJidF9kZXZlbnVtX2NiX3QgKmNi IiAidm9pZCAqYXJnIgogLkZ0IGludAorLkZuIGJ0X2Rldm9wZW4gImNoYXIgY29uc3QgKmRldm5h bWUiCisuRnQgaW50CisuRm4gYnRfZGV2Y2xvc2UgImludCBzIgorLkZ0IGludAorLkZuIGJ0X2Rl dnNlbmQgImludCBzIiAidWludDE2X3Qgb3Bjb2RlIiAidm9pZCAqcGFyYW0iICJzaXplX3QgcGxl biIKKy5GdCBpbnQKKy5GbiBidF9kZXZyZWN2ICJpbnQgcyIgInVpbnQ4X3QgKmJ1ZiIgInNpemVf dCBzaXplIiAidGltZV90IHRvIgorLkZ0IGludAorLkZuIGJ0X2RldnJlcSAiaW50IHMiICJzdHJ1 Y3QgYnRfZGV2cmVxICpyIiAidGltZV90IHRvIgorLkZ0IGludAorLkZuIGJ0X2RldmZpbHRlciAi aW50IHMiICJzdHJ1Y3QgYnRfZGV2ZmlsdGVyIGNvbnN0ICpuZXciICJzdHJ1Y3QgYnRfZGV2Zmls dGVyICpvbGQiCisuRnQgdm9pZAorLkZuIGJ0X2RldmZpbHRlcl9wa3Rfc2V0ICJzdHJ1Y3QgYnRf ZGV2ZmlsdGVyICpmaWx0ZXIiICJpbnQgdHlwZSIKKy5GdCB2b2lkCisuRm4gYnRfZGV2ZmlsdGVy X3BrdF9jbHQgInN0cnVjdCBidF9kZXZmaWx0ZXIgKmZpbHRlciIgImludCB0eXBlIgorLkZ0IGlu dAorLkZuIGJ0X2RldmZpbHRlcl9wa3RfdHN0ICJzdHJ1Y3QgYnRfZGV2ZmlsdGVyIGNvbnN0ICpm aWx0ZXIiICJpbnQgdHlwZSIKKy5GdCB2b2lkCisuRm4gYnRfZGV2ZmlsdGVyX2V2dF9zZXQgInN0 cnVjdCBidF9kZXZmaWx0ZXIgKmZpbHRlciIgImludCBldmVudCIKKy5GdCB2b2lkCisuRm4gYnRf ZGV2ZmlsdGVyX2V2dF9jbHQgInN0cnVjdCBidF9kZXZmaWx0ZXIgKmZpbHRlciIgImludCBldmVu dCIKKy5GdCBpbnQKKy5GbiBidF9kZXZmaWx0ZXJfZXZ0X3RzdCAic3RydWN0IGJ0X2RldmZpbHRl ciBjb25zdCAqZmlsdGVyIiAiaW50IGV2ZW50IgorLkZ0IGludAorLkZuIGJ0X2RldmlucXVpcnkg ImNoYXIgY29uc3QgKmRldm5hbWUiICJ0aW1lX3QgbGVuZ3RoIiAiaW50IG51bV9yc3AiICJzdHJ1 Y3QgYnRfZGV2aW5xdWlyeSAqKmlpIgorLkZ0IGludAogLkZuIGJkYWRkcl9zYW1lICJjb25zdCBi ZGFkZHJfdCAqYSIgImNvbnN0IGJkYWRkcl90ICpiIgogLkZ0IGludAogLkZuIGJkYWRkcl9hbnkg ImNvbnN0IGJkYWRkcl90ICphIgpAQCAtMzExLDYgKzM1NCwyMTEgQEAKIG9yIC0xIGlmIGFuIGVy cm9yIG9jY3VycmVkLgogLlBwCiBUaGUKKy5GbiBidF9kZXZvcGVuCitmdW5jdGlvbiBvcGVucyBC bHVldG9vdGggZGV2aWNlIHdpdGggdGhlIGdpdmVuCisuRmEgZGV2bmFtZQorYW5kIHJldHVybnMg Y29ubmVjdGVkIGFuZCBib3VuZAorLkR2IEhDSQorc29ja2V0LgorVGhlIGZ1bmN0aW9uIHJldHVy bnMgLTEgaWYgYW4gZXJyb3IgaGFzIG9jY3VycmVkLgorLlBwCitUaGUKKy5GbiBidF9kZXZjbG9z ZQorY2xvc2VzIHBhc3NlZAorLkR2IEhDSQorc29ja2V0CisuRmEgcyAsCitwcmV2aW91c2x5IG9i dGFpbmVkIHdpdGgKKy5YciBidF9kZXZvcGVuIDMgLgorLlBwCitUaGUKKy5GbiBidF9kZXZzZW5k CitmdW5jdGlvbiBzZW5kcyBCbHVldG9vdGgKKy5EdiBIQ0kKK2NvbW1hbmQgd2l0aCB0aGUgZ2l2 ZW4KKy5GYSBvcGNvZGUKK3RvIHRoZSBwcm92aWRlZCBzb2NrZXQKKy5GYSBzICwKK3ByZXZpb3Vz bHkgb2J0YWluZWQgd2l0aAorLlhyIGJ0X2Rldm9wZW4gMyAuCitUaGUKKy5GYSBvcGNvZGUKK3Bh cmFtZXRlciBpcyBleHBwZWN0ZWQgdG8gYmUgaW4gdGhlIGhvc3QgYnl0ZSBvcmRlci4KK1RoZQor LkZhIHBhcmFtCithbmQKKy5GYSBwbGVuCitwYXJhbWV0ZXJzIHNwZWNpZnkgY29tbWFuZCBwYXJh bWV0ZXJzLgorVGhlIGZ1bmN0aW9uIHJldHVybnMgMCBvbiBzdWNjZXNzLAorb3IgLTEgaWYgYW4g ZXJyb3Igb2NjdXJyZWQuCisuUHAKK1RoZQorLkZuIGJ0X2RldnJlY3YKK2Z1bmN0aW9uIHJlY2Vp dmVzIG9uZSBCbHVldG9vdGgKKy5EdiBIQ0kKK2V2ZW50IHBhY2tldCBmcm9tIHRoZSBzb2NrZXQK Ky5GYSBzICwKK3ByZXZpb3VzbHkgb2J0YWluZWQgd2l0aAorLlhyIGJ0X2Rldm9wZW4gMyAuCitU aGUgZXZlbnQgcGFja2V0IGlzIHBsYWNlZCBpbnRvIHRoZSBwcm92aWRlZCBidWZmZXIKKy5GYSBi dWYKK29mIHNpemUKKy5GYSBzaXplIC4KK1RoZQorLkZhIHRvCitwYXJhbWV0ZXIgc3BlY2lmaWVz IHJlY2VpdmUgdGltZW91dCBpbiBzZWNvbmRzLgorVGhlIGZ1bmN0aW9uIHJldHVybnMgdG90YWwg bnVtYmVyIG9mIGJ5dGVzIHJlY2V2aWVkLAorb3IgLTEgaWYgYW4gZXJyb3Igb2NjdXJyZWQuCisu UHAKK1RoZQorLkZuIGJ0X2RldnJlcQorZnVuY3Rpb24gbWFrZXMgQmx1ZXRvb3RoCisuRHYgSENJ CityZXF1ZXN0IHRvIHRoZSBzb2NrZXQKKy5GYSBzICwKK3ByZXZpb3VzbHkgb2J0YWluZWQgd2l0 aAorLlhyIGJ0X2Rldm9wZW4gMyAuCitUaGUgZnVuY3Rpb24gd2lsbCBzZW5kIHRoZSBzcGVjaWZp ZWQgY29tbWFuZCBhbmQgd2lsbCB3YWl0IGZvciB0aGUgc3BlY2lmaWVkCitldmVudCwKK29yIHRp bWVvdXQKKy5GYSB0bworc2Vjb25kcyB0byBvY2N1ci4KK1RoZQorLlZ0IGJ0X2RldnJlcQorc3Ry dWN0dXJlIGlzIGRlZmluZWQgYXMgZm9sbG93cworLkJkIC1saXRlcmFsIC1vZmZzZXQgaW5kZW50 CitzdHJ1Y3QgYnRfZGV2cmVxCit7CisgICAgICAgIHVpbnQxNl90ICAgICAgICBvcGNvZGU7Cisg ICAgICAgIHVpbnQxNl90ICAgICAgICBldmVudDsKKyAgICAgICAgdm9pZCAgICAgICAgICAgICpj cGFyYW07CisgICAgICAgIGludCAgICAgICAgICAgICBjbGVuOworICAgICAgICB2b2lkICAgICAg ICAgICAgKnJwYXJhbTsKKyAgICAgICAgaW50ICAgICAgICAgICAgIHJsZW47Cit9OworLkVkCisu UHAKK1RoZQorLkZhIG9wY29kZQorZmllbGQgc3BlY2lmaWVzIHRoZSBjb21tYW5kIGFuZCBpcyBl eHBlY3RlZCB0byBiZSBpbiB0aGUgaG9zdCBieXRlIG9yZGVyLgorVGhlCisuRmEgY3BhcmFtCith bmQKKy5GYSBjbGVuCitmaWVsZHMgc3BlY2lmeSBjb21tYW5kIHBhcmFtZXRlcnMgZGF0YSBhbmQg Y29tbWFuZCBwYXJhbWV0ZXJzIGRhdGEgc2l6ZQorcmVzcGVjdGl2ZWx5LgorVGhlCisuRmEgZXZl bnQKK2ZpZWxkIHNwZWNpZmllcyB3aGljaCBCbHVldG9vdGgKKy5EdiBIQ0kKK2V2ZW50IElEIHRo ZSBmdW5jdGlvbiBzaG91bGQgd2FpdCBmb3IuCitUaGUKKy5GYSBycGFyYW0KK2FuZAorLkZhIHJs ZW4KK3BhcmFtZXRlcnMgc3BlY2lmeSBidWZmZXIgYW5kIGJ1ZmZlciBzaXplIHJlc3BlY3RpdmVs eSB3aGVyZSByZXR1cm4KK3BhcmFtZXRlcnMgc2hvdWxkIGJlIHBsYWNlZC4KK1RoZSBmdW5jdGlv biByZXR1cm5zIDAgb24gc3VjY2Vzcywgb3IgLTEgaWYgYW4gZXJyb3Igb2NjdXJyZWQuCisuUHAK K1RoZQorLkZuIGJ0X2RldmZpbHRlcgorY29udHJvbHMgdGhlIGxvY2FsCisuRHYgSENJCitmaWx0 ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSBzb2NrZXQKKy5GYSBzICwKK3ByZXZpb3VzbHkgb2J0YWlu ZWQgd2l0aAorLlhyIGJ0X2Rldm9wZW4gMyAuCitGaWx0ZXJpbmcgY2FuIGJlIGRvbmUgb24gcGFj a2V0IHR5cGVzLCBpLmUuCisuRHYgQUNMICwKKy5EdiBTQ08gb3IKKy5EdiBIQ0kKK2V2ZW50IHBh Y2tldHMsIGFuZCwgaW4gYWRkaXRpb24sIG9uCisuRHYgSENJCitldmVudCBJRHMuCitCZWZvcmUg YXBwbHlpbmcKKy5GYSBuZXcKK2ZpbHRlciAoaWYgcHJvdmlkZWQpIHRoZSBmdW5jdGlvbiB3aWxs IHRyeSB0byBvYnRhaW4gY3VycmVudCBmaWx0ZXIKK2Zyb20gdGhlIHNvY2tldAorLkZhIHMKK2Fu ZCBwbGFjZSBpdCBpbnRvIHRoZQorLkZhIG9sZAorcGFyYW1ldGVyIChpZiBwcm92aWRlZCkuCitU aGUgZnVuY3Rpb24gcmV0dXJucyAwIG9uIHN1Y2Nlc3MsIG9yIC0xIGlmIGFuIGVycm9yIG9jY3Vy cmVkLgorLlBwCitUaGUKKy5GbiBidF9kZXZmaWx0ZXJfcGt0X3NldCAsCisuRm4gYnRfZGV2Zmls dGVyX3BrdF9jbHIgCithbmQKKy5GbiBidF9kZXZmaWx0ZXJfcGt0X3RzdAorZnVuY3Rpb25zIGNh biBiZSB1c2VkIHRvIG1vZGlmeSBhbmQgdGVzdAorLkR2IEhDSQorZmlsdGVyCisuRmEgZmlsdGVy IC4KK1RoZQorLkZhIHR5cGUKK3BhcmFtZXRlciBzcGVjaWZpZXMKKy5EdiBIQ0kKK3BhY2tldCB0 eXBlLgorLlBwCitUaGUKKy5GbiBidF9kZXZmaWx0ZXJfZXZ0X3NldCAsCisuRm4gYnRfZGV2Zmls dGVyX2V2dF9jbHIgCithbmQKKy5GbiBidF9kZXZmaWx0ZXJfZXZ0X3RzdAorZnVuY3Rpb25zIGNh biBiZSB1c2VkIHRvIG1vZGlmeSBhbmQgdGVzdAorLkR2IEhDSQorZXZlbnQgZmlsdGVyCisuRmEg ZmlsdGVyIC4KK1RoZQorLkZhIGV2ZW50CitwYXJhbWV0ZXIgc3BlY2lmaWVzCisuRHYgSENJCitl dmVudCBJRC4KKy5QcAorVGhlCisuRm4gYnRfZGV2aW5xdWlyeQorZnVuY3Rpb24gcGVyZm9ybXMg Qmx1ZXRvb3RoIGlucXVpcnkuCitUaGUKKy5GYSBkZXZuYW1lCitwYXJhbWV0ZXIgc3BlY2lmaWVz IHdoaWNoIGxvY2FsIEJsdWV0b290aCBkZXZpY2Ugc2hvdWxkIHBlcmZvcm0gYW4gaW5xdWlyeS4K K0lmIG5vdCBzZWNpZmllZCwgaS5lLgorLkR2IE5VTEwgLAordGhlbiBmaXJzdCBhdmFpbGFibGUg ZGV2aWNlIHdpbGwgYmUgdXNlZC4KK1RoZQorLkZhIGxlbmd0aAorcGFyYW1ldGVycyBzcGVjaWZp ZXMgdGhlIHRvdGFsIGxlbmd0aCBvZiBhbiBpbnF1aXJ5IGluIHNlY29uZHMuCitJZiBub3Qgc3Bl Y2lmaWVkLCBpLmUuIDAsIGRlZmF1bHQgdmFsdWUgd2lsbCBiZSB1c2VkLgorVGhlCisuRmEgbnVt X3JzcAorcGFyYW1ldGVyIHNwZWNpZmllcyB0aGUgbnVtYmVyIG9mIHJlc3BvbnNlcyB0aGF0IGNh biBiZSByZWNlaXZlZCBiZWZvcmUKK3RoZSBpbnF1aXJ5IGlzIGhhbHRlZC4KK0lmIG5vdCBzcGVj aWZpZWQsIGkuZS4gMCwgZGVmYXVsdCB2YWx1ZSB3aWxsIGJlIHVzZWQuCitUaGUKKy5GYSBpaQor cGFyYW1ldGVyIHNwZWNpZmllcyB3aGVyZSB0byBwbGFjZSBpbnF1aXJ5IHJlc3VsdHMuCitPbiBz dWNjZXNzLCB0aGUgZnVuY3Rpb24gd2lsbCByZXR1cm4gdG90YWwgbnVtYmVyIG9mIGlucXVpcnkg cmVzdWx0cywKK3dpbGwgYWxsb2NhdGUgYnVmZmVyIHRvIHN0b3JlIGFsbCB0aGUgaW5xdWlyeSBy ZXN1bHRzIGFuZAord2lsbCByZXR1cm4gcG9pbnRlciB0byB0aGUgYWxsb2NhdGVkIGJ1ZmZlciBp biB0aGUKKy5GYSBpaQorcGFyYW1ldGVyLgorSXQgaXMgdXAgdG8gdGhlIGNhbGxlciBvZiB0aGUg ZnVuY3Rpb24gdG8gZGlzcG9zZSBvZiB0aGUgYnVmZmVyLgorVGhlIGZ1bmN0aW9uIHJldHVybnMg LTEgaWYgYW4gZXJyb3IgaGFzIG9jY3VycmVkLgorVGhlCisuVnQgYnRfZGV2aW5xdWlyeQorc3Ry dWN0dXJlIGlzIGRlZmluZWQgYXMgZm9sbG93cworLkJkIC1saXRlcmFsIC1vZmZzZXQgaW5kZW50 CitzdHJ1Y3QgYnRfZGV2aW5xdWlyeSB7CisgICAgICAgIGJkYWRkcl90ICAgICAgICBiZGFkZHI7 CisgICAgICAgIHVpbnQ4X3QgICAgICAgICBwc2Nhbl9yZXBfbW9kZTsKKyAgICAgICAgdWludDhf dCAgICAgICAgIHBzY2FuX3BlcmlvZF9tb2RlOworICAgICAgICB1aW50OF90ICAgICAgICAgZGV2 X2NsYXNzWzNdOworICAgICAgICB1aW50MTZfdCAgICAgICAgY2xvY2tfb2Zmc2V0OworICAgICAg ICBpbnQ4X3QgICAgICAgICAgcnNzaTsKKyAgICAgICAgdWludDhfdCAgICAgICAgIGRhdGFbMjQw XTsKK307CisuRWQKKy5QcAorVGhlCiAuRm4gYmRhZGRyX3NhbWUgLAogLkZuIGJkYWRkcl9hbnkK IGFuZApAQCAtNDQ0LDYgKzY5Miw2IEBACiAuU2ggQVVUSE9SUwogLkFuIE1ha3NpbSBZZXZtZW5r aW4gQXEgbV9ldm1lbmtpbkB5YWhvby5jb20KIC5TaCBCVUdTCi1UaGVzZSBmdW5jdGlvbnMgdXNl IHN0YXRpYyBkYXRhIHN0b3JhZ2U7CitTb21lIG9mIHRob3NlIGZ1bmN0aW9ucyB1c2Ugc3RhdGlj IGRhdGEgc3RvcmFnZTsKIGlmIHRoZSBkYXRhIGlzIG5lZWRlZCBmb3IgZnV0dXJlIHVzZSwgaXQg c2hvdWxkIGJlCiBjb3BpZWQgYmVmb3JlIGFueSBzdWJzZXF1ZW50IGNhbGxzIG92ZXJ3cml0ZSBp dC4KSW5kZXg6IGJsdWV0b290aC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGJsdWV0b290aC5oCShyZXZpc2lv biAxOTEwMTIpCisrKyBibHVldG9vdGguaAkod29ya2luZyBjb3B5KQpAQCAtMzksNiArMzksNyBA QAogI2luY2x1ZGUgPHN5cy9lbmRpYW4uaD4KICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KICNpbmNs dWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSA8c3lzL3Vpby5oPgogI2luY2x1ZGUgPHN5cy91 bi5oPgogI2luY2x1ZGUgPGVycm5vLmg+CiAjaW5jbHVkZSA8bmV0ZGIuaD4KQEAgLTQ2LDYgKzQ3 LDcgQEAKICNpbmNsdWRlIDxuZXRncmFwaC9ibHVldG9vdGgvaW5jbHVkZS9uZ19oY2kuaD4KICNp bmNsdWRlIDxuZXRncmFwaC9ibHVldG9vdGgvaW5jbHVkZS9uZ19sMmNhcC5oPgogI2luY2x1ZGUg PG5ldGdyYXBoL2JsdWV0b290aC9pbmNsdWRlL25nX2J0c29ja2V0Lmg+CisjaW5jbHVkZSA8dGlt ZS5oPgogCiBfX0JFR0lOX0RFQ0xTCiAKQEAgLTEyOSw4ICsxMzEsNDggQEAKIAl1aW50OF90CQlf cGFkZGluZ1syMF07CS8qIGxlYXZlIHNwYWNlIGZvciBmdXR1cmUgYWRkaXRpb25zICovCiB9Owog CitzdHJ1Y3QgYnRfZGV2cmVxCit7CisJdWludDE2X3QJb3Bjb2RlOworCXVpbnQxNl90CWV2ZW50 OworCXZvaWQJCSpjcGFyYW07CisJc2l6ZV90CQljbGVuOworCXZvaWQJCSpycGFyYW07CisJc2l6 ZV90CQlybGVuOworfTsKKworc3RydWN0IGJ0X2RldmZpbHRlciB7CisJYml0c3RyX3QJYml0X2Rl Y2wocGFja2V0X21hc2ssIDgpOworCWJpdHN0cl90CWJpdF9kZWNsKGV2ZW50X21hc2ssIDI1Nik7 Cit9OworCitzdHJ1Y3QgYnRfZGV2aW5xdWlyeSB7CisJYmRhZGRyX3QgICAgICAgIGJkYWRkcjsK Kwl1aW50OF90ICAgICAgICAgcHNjYW5fcmVwX21vZGU7CisJdWludDhfdCAgICAgICAgIHBzY2Fu X3BlcmlvZF9tb2RlOworCXVpbnQ4X3QgICAgICAgICBkZXZfY2xhc3NbM107CisJdWludDE2X3Qg ICAgICAgIGNsb2NrX29mZnNldDsKKwlpbnQ4X3QgICAgICAgICAgcnNzaTsKKwl1aW50OF90ICAg ICAgICAgZGF0YVsyNDBdOworfTsKKwogdHlwZWRlZiBpbnQJKGJ0X2RldmVudW1fY2JfdCkoaW50 LCBzdHJ1Y3QgYnRfZGV2aW5mbyBjb25zdCAqLCB2b2lkICopOwogCitpbnQJCWJ0X2Rldm9wZW4g KGNoYXIgY29uc3QgKmRldm5hbWUpOworaW50CQlidF9kZXZjbG9zZShpbnQgcyk7CitpbnQJCWJ0 X2RldnNlbmQgKGludCBzLCB1aW50MTZfdCBvcGNvZGUsIHZvaWQgKnBhcmFtLCBzaXplX3QgcGxl bik7CitpbnQJCWJ0X2RldnJlY3YgKGludCBzLCB1aW50OF90ICpidWYsIHNpemVfdCBzaXplLCB0 aW1lX3QgdG8pOworaW50CQlidF9kZXZyZXEgIChpbnQgcywgc3RydWN0IGJ0X2RldnJlcSAqciwg dGltZV90IHRvKTsKK2ludAkJYnRfZGV2ZmlsdGVyKGludCBzLCBzdHJ1Y3QgYnRfZGV2ZmlsdGVy IGNvbnN0ICpuZXcsCisJCQkgICAgIHN0cnVjdCBidF9kZXZmaWx0ZXIgKm9sZCk7Cit2b2lkCQli dF9kZXZmaWx0ZXJfcGt0X3NldChzdHJ1Y3QgYnRfZGV2ZmlsdGVyICpmaWx0ZXIsIGludCB0eXBl KTsKK3ZvaWQJCWJ0X2RldmZpbHRlcl9wa3RfY2xyKHN0cnVjdCBidF9kZXZmaWx0ZXIgKmZpbHRl ciwgaW50IHR5cGUpOworaW50CQlidF9kZXZmaWx0ZXJfcGt0X3RzdChzdHJ1Y3QgYnRfZGV2Zmls dGVyIGNvbnN0ICpmaWx0ZXIsIGludCB0eXBlKTsKK3ZvaWQJCWJ0X2RldmZpbHRlcl9ldnRfc2V0 KHN0cnVjdCBidF9kZXZmaWx0ZXIgKmZpbHRlciwgaW50IGV2ZW50KTsKK3ZvaWQJCWJ0X2RldmZp bHRlcl9ldnRfY2xyKHN0cnVjdCBidF9kZXZmaWx0ZXIgKmZpbHRlciwgaW50IGV2ZW50KTsKK2lu dAkJYnRfZGV2ZmlsdGVyX2V2dF90c3Qoc3RydWN0IGJ0X2RldmZpbHRlciBjb25zdCAqZmlsdGVy LCBpbnQgZXZlbnQpOworaW50CQlidF9kZXZpbnF1aXJ5KGNoYXIgY29uc3QgKmRldm5hbWUsIHRp bWVfdCBsZW5ndGgsIGludCBudW1fcnNwLAorCQkJICAgICAgc3RydWN0IGJ0X2RldmlucXVpcnkg KippaSk7CiBpbnQJCWJ0X2RldmluZm8gKHN0cnVjdCBidF9kZXZpbmZvICpkaSk7CiBpbnQJCWJ0 X2RldmVudW0gKGJ0X2RldmVudW1fY2JfdCAqY2IsIHZvaWQgKmFyZyk7CiAKSW5kZXg6IE1ha2Vm aWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIE1ha2VmaWxlCShyZXZpc2lvbiAxOTEwMTIpCisrKyBNYWtlZmls ZQkod29ya2luZyBjb3B5KQpAQCAtMzMsNiArMzMsMTkgQEAKIE1MSU5LUys9CWJsdWV0b290aC4z IGJ0X2RldmluZm8uMwogTUxJTktTKz0JYmx1ZXRvb3RoLjMgYnRfZGV2ZW51bS4zCiAKK01MSU5L Uys9CWJsdWV0b290aC4zIGJ0X2Rldm9wZW4uMworTUxJTktTKz0JYmx1ZXRvb3RoLjMgYnRfZGV2 Y2xvc2UuMworTUxJTktTKz0JYmx1ZXRvb3RoLjMgYnRfZGV2c2VuZC4zCitNTElOS1MrPQlibHVl dG9vdGguMyBidF9kZXZyZXEuMworTUxJTktTKz0JYmx1ZXRvb3RoLjMgYnRfZGV2ZmlsdGVyLjMK K01MSU5LUys9CWJsdWV0b290aC4zIGJ0X2RldmZpbHRlcl9wa3Rfc2V0LjMKK01MSU5LUys9CWJs dWV0b290aC4zIGJ0X2RldmZpbHRlcl9wa3RfY2xyLjMKK01MSU5LUys9CWJsdWV0b290aC4zIGJ0 X2RldmZpbHRlcl9wa3RfdHN0LjMKK01MSU5LUys9CWJsdWV0b290aC4zIGJ0X2RldmZpbHRlcl9l dnRfc2V0LjMKK01MSU5LUys9CWJsdWV0b290aC4zIGJ0X2RldmZpbHRlcl9ldnRfY2xyLjMKK01M SU5LUys9CWJsdWV0b290aC4zIGJ0X2RldmZpbHRlcl9ldnRfdHN0LjMKK01MSU5LUys9CWJsdWV0 b290aC4zIGJ0X2RldmlucXVpcnkuMworCiBNTElOS1MrPQlibHVldG9vdGguMyBiZGFkZHJfc2Ft ZS4zCiBNTElOS1MrPQlibHVldG9vdGguMyBiZGFkZHJfYW55LjMKIE1MSU5LUys9CWJsdWV0b290 aC4zIGJkYWRkcl9jb3B5LjMK --0016361e86c09175d40467c870d7-- From owner-freebsd-bluetooth@FreeBSD.ORG Sat Apr 18 07:52:30 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99D7C106564A for ; Sat, 18 Apr 2009 07:52:30 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7E68FC0A for ; Sat, 18 Apr 2009 07:52:30 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1Lv5Ld-000599-Fg; Sat, 18 Apr 2009 08:52:25 +0100 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19664-02; Sat, 18 Apr 2009 08:52:25 +0100 (BST) Received: from [10.217.47.227] (helo=Inbox) by smtpbarns01 with esmtp (Exim 4.50) id 1Lv5La-00058x-HH; Sat, 18 Apr 2009 08:52:25 +0100 MIME-Version: 1.0 content-class: From: Iain Hibbert Date: Sat, 18 Apr 2009 08:51:06 +0100 Importance: normal X-Priority: 3 To: Maksim Yevmenkin Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: RE: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 07:52:30 -0000 > thanks for the feedback. i'm attaching revisited patch. please take a > look and let me know if this is something you happy with. (pls ignore typos & bad formatting, am on mobile device :) Bt_devrecv() should probably take void * for buffer? Also manpage suggests= it will only receive hci events. Do you think its worth doing some validat= ion of received data? (eg return EIO for truncated reads?) Bt_devinquiry() should probably restore the filter after use? Also needs t= o ensure hci event packets are enabled? Bt_devreq() needs to set/restore a filter too In bt_devreq structure event should be uint8_t? Also clen and rlen should b= e size_t Do you think its worth to cook dev_class into a normalised host numeric val= ue rather than 3 bytes ? Probably need to specifically mention that the inquiry response to be relea= sed using free() in manpage? Something i thought about on the train yesterday but can't visualise on the= small screen. For device inquiry did you consider using a callback method = (as per devenum) in stead of returning the structure array? At least i reca= ll my nokia would show the list building (but perhaps that was when it got = the names) and this windows mobile device does show the raw list in progres= s (though stupidly just displays a list of 'unknown device' until it gets t= he names :) Regards, iain=