From owner-freebsd-fs Sun Dec 12 0:13:17 1999 Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 431C915096; Sun, 12 Dec 1999 00:13:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 11CA61CD79D; Sun, 12 Dec 1999 00:13:13 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 12 Dec 1999 00:13:12 -0800 (PST) From: Kris Kennaway To: Pekka Savola Cc: freebsd-fs@freebsd.org Subject: Re: Deleting a directory on ext2fs crashed the system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 11 Dec 1999, Pekka Savola wrote: > Deleting one directory on an ext2fs crashed my FreeBSD 3.4-RC system up > pretty badly: > > panic: bmemfree: removing a buffer when not in queue > Syncing disks ... [crash] Please read the section in the handbook on kernel debugging. You need to post a crashdump before someone can have a hope of fixing your problem. > After that, I couldn't log in in with SSH, or log in from console > (keyboard didn't seem to function apart from ALT-Fx). NAT'ed connections > stayed alive, though, and the system was pingable. Err, if the system crashed, then none of these would have worked. Or do you mean you got the misbehaviour when you rebooted? That is still very odd. > Btw, are there any good ext2 fsck tools? I'm using the ones from Linux > with emulation, but there are some unimplemented system calls or such. That might be the cause of your problem, if you'd previously run these on the partition prior to the crash. An unimplemented syscall means it can't do everything it was trying to, which may hose your filesystem. I think NetBSD have a fsck_ext2fs - you'd have better luck with that. Or if you want to use the linux one, you'll have to provide some more verbose problem reporting to the emulation list (i.e. what missing syscalls?) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Dec 15 11:44:31 1999 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 87C8415570 for ; Wed, 15 Dec 1999 11:44:06 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id OAA22945 for ; Wed, 15 Dec 1999 14:44:21 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Wed, 15 Dec 1999 14:44:21 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-fs@freebsd.org Subject: Request for objections: extended attribute and ACL interfaces Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2036405370-945287061=:22637" Content-ID: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-2036405370-945287061=:22637 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: As previously discussed in some detail on freebsd-arch, freebsd-security, and posix1e, I have been working on adding support for file system access control lists (among other things), and the supporting extended attribute interface required to store additional meta-data in UFS and other file systems. After a fair amount of hashing out, the interfaces seem to please most interested parties (i.e., we've verified that the attribute interface is sufficiently flexible for the needs of the HPFS folk, the attribute interface provides the functionality for capabilities, acls, mandatory access control labels, privileged code signatures, etc, and the acl interface can handle posix.1e acls, as well as providing a mechanism for managing other acl schemes, such as those in AFS and Coda), and we're planning to commit these interfaces on Friday, unless objections are raised. Please note that these are only the interfaces, not the actually code itself, but standardizing the interfaces (especially vfs calls) makes it easy to add the code later via kernel modules, and used in other file systems currently provided by third parties (ARLA and Coda in particular). Attached please find four files, text introductions to both extended attributes and acls, and the sys/ header files providing more detailed information on the specifics of the interfaces. The extended descriptions include rationale, information on implementations in other operating systems, and the interface that descriptions and semantics. Commited would be: Changes to vnode_if.src to describe the new calls Changes to mount.h and vfs_default.c to add the vfsop calls Changes to vfsops arrays for various file systems so that they return EOPNOTSUPP for the vfs calls Syscalls in vfs_syscalls.c to perform name lookup and invoke the vfsops/vnops Addition of kern/kern_acl.c to provide common routines for third party file systems. No changes would be made to underlying file systems other than to allow them to return EOPNOTSUPP for the vfs call; with vnops this is not necessary as the vnode interface will return EOPNOTSUPP for any fs not supporting a call. The UFS EA supporting code would not be committed, as it is experimental and not well tested. Neither will the UFS ACLs over EAs support. Both of these will be made available soon, however, and will rely on having vnops/vfsops/syscalls assigned and available. :-) Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services --0-2036405370-945287061=:22637 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="extattr_details.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: RXh0ZW5kZWQgQXR0cmlidXRlcw0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJ bnRyb2R1Y3Rpb24NCg0KRXh0ZW5kZWQgQXR0cmlidXRlcyBwcm92aWRlIHRo ZSBhYmlsaXR5IGZvciB0aGUga2VybmVsIG9yIHVzZXJsYW5kIHByb2Nlc3Nl cw0KdG8gYXNzb2NpYXRlIGFkZGl0aW9uYWwgbWV0YS1kYXRhIHdpdGggZmls ZXMgYW5kIGRpcmVjdG9yaWVzLg0KDQoNClJhdGlvbmFsZQ0KDQpUaGVyZSBh cmUgYSBudW1iZXIgb2YgcG90ZW50aWFsIGFwcGxpY2F0aW9ucyBmb3IgZXh0 ZW5kZWQgYXR0cmlidXRlcywgYnV0DQp0aGUgZHJpdmluZyBmb3JjZSBiZWhp bmQgdGhlIGN1cnJlbnQgaW1wbGVtZXRhdGlvbiBpcyBleHRlbmRlZCBzZWN1 cml0eQ0Kc2VydmljZXM6IG1hbnkgbW9yZSBjb21wbGV4IHNlY3VyaXR5IG1l Y2hhbmlzbXMgcmVxdWlyZSBhZGRpdGlvbmFsIHN0YXRlDQphc3NvY2lhdGVk IHdpdGggZWFjaCBmaWxlIG9yIGRpcmVjdG9yeS4gIEZvciBleGFtcGxlLCBB Q0xzIHJlcXVpcmUgcGVyLQ0KZmlsZSBzdG9yYWdlLCBhcyBkbyBjYXBhYmls aXRpZXMsIGFuZCBNQUMgbGFiZWxzLiAgSW1wbGVtZW50YXRpb25zIG9mDQph bGwgb2YgdGhlc2UgZmVhdHVyZXMgZXhpc3QgZm9yIEZyZWVCU0QsIGJ1dCBh d2FpdCBzdG9yYWdlIGluIHRoZSBmaWxlDQpzeXN0ZW0uICBFeHRlbmRlZCBh dHRyaWJ1dGVzIHByb3ZpZGUgYSBnZW5lcmFsaXplZCB3YXkgaW4gd2hpY2gg dG8gbWFuYWdlDQp0aGlzIGFkZGl0aW9uYWwgbWV0YS1kYXRhLCBmb3IgZmls ZSBzdG9yZXMgdGhhdCBhcmUgZG8gbm90IGFsbG93IGZvcg0Kc3RvcmluZyB0 aGlzIGRhdGEgZGlyZWN0bHkuDQoNCkFkZGl0aW9uYWxseSwgdGhlcmUgYXJl IGEgbnVtYmVyIG9mIGV4aXN0aW5nIGZpbGUgc3lzdGVtcyB0aGF0IHN1cHBv cnQNCmV4dGVuZGVkIGF0dHJpYnV0ZXMsIGFuZCBpdCBpcyBkZXNpcmFibGUg dG8gZXhwb3NlIHRoaXMgZnVuY3Rpb25hbGl0eSBpbg0KRnJlZUJTRCB3aGVu IHByb2Nlc3NlcyBhcmUgYWNjZXNzaW5nIGRhdGEgc3RvcmVkIGluIHRoZSBm aWxlIHN5c3RlbS4NCg0KUHJvdmlkaW5nIGEgc2luZ2xlIGFuZCBjb21wcmVo ZW5zaXZlIHZub2RlIGFuZCBzeXNjYWxsIGludGVyZmFjZSB3aWxsDQphbGxv dyB0aGlzIHN0b3JhZ2UgYW5kIGFjY2VzcyB0byBvY2N1ciBpbiBhIGNvbnNp c3RlbnQgd2F5IGFjcm9zcyBmaWxlDQpzeXN0ZW1zLg0KDQoNClNlcnZpY2Vz DQoNCkVhY2ggdm5vZGUgbWF5IG5vdyBoYXZlIGEgc2VyaWVzIG9mIG5hbWVk IGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3aXRoIGl0LA0KaW4gYWRkaXRpb24g dG8gdGhlIGV4aXN0aW5nIGZsYXQgZmlsZSBkYXRhIGFjY2Vzc2libGUgdmlh IGN1cnJlbnQgY2FsbHMsDQphbmQgZXhpc3RpbmcgYXR0cmlidXRlcy4gIFRo ZSBzaW1wbGlzdCB3YXkgdG8gZGVzY3JpYmUgdGhlIHNlbWFudGljcyBpcw0K dG8gY29tcGFyZSBuYW1lZCBhdHRyaWJ1dGVzIHRvIGEgc2V0IG9mIGVudmly b25tZW50YWwgdmFyaWFibGUgYXNzaWdubWVudHMuDQpBIHZhcmlhYmxlIG1h eSBiZSBkZWZpbmVkIG9yIHVuZGVmaW5lZCwgYW5kIGlmIGRlZmluZWQsIGl0 IG1heSBoYXZlIDAgb3INCm1vcmUgYnl0ZXMgb2YgZGF0YSBhc3NvY2lhdGVk IHdpdGggaXQuICBXaGlsZSBpdCBtaWdodCBiZSBwb3NzaWJsZSB0bw0KbW9k aWZ5IGFuIGF0dHJpYnV0ZSwgbWFueSBpbXBsZW1lbnRhdGlvbnMgbGltaXQg dGhpcyBiZWhhdmlvciB0byByZXBsYWNpbmcNCmFuIGV4aXN0aW5nIHZhbHVl IHJhdGhlciB0aGFuIGVkaXRpbmcgaXQgaW4gdGhlIHN0eWxlIG9mIFZPUF9X UklURQ0KYWN0aW5nIG9uIGEgc2VjdGlvbiBvZiBhIGZsYXQgZmlsZS4gIEF0 dHJpYnV0ZXMgbWF5IGJlIHJldHJpZXZlZCwgc2V0LA0KYW5kIHJlbW92ZWQg KHRvIHRha2UgYSBuYW1lIGZyb20gZGVmaW5lZCB0byB1bmRlZmluZWQpLiAg DQoNClRoZSB2bm9kZSBpbnRlcmZhY2UgbGltaXRzIG5hbWVzIHRvIG51bGwt dGVybWluYXRlZCBzdHJpbmdzLCBidXQgYWxsb3dzDQphdHRyaWJ1dGUgdmFs dWVzIHRvIGJlIGFueSBiaW5hcnkgYmxvYiBkZXNjcmliYWJsZSB1c2luZyBh IHN0cnVjdCB1aW8uDQpVbmRlcmx5aW5nIGZpbGUgc3lzdGVtcyBtYXkgcGxh Y2UgYWRkaXRpb25hbCBsaW1pdHMgb24gdGhlIHNpemUgYW5kDQpzdHJ1Y3R1 cmUgb2YgbmFtZXMsIGFzIHdlbGwgYXMgdGhlIHNpemUgb2YgZGF0YS4gIEZp bGUgc3lzdGVtcyBtYXkgYWxzbw0KcGxhY2Ugc3BlY2lmaWMgaW50ZXJwcmV0 YXRpb25zIG9uIHNwZWNpZmljIG5hbWVzLCBsaW1pdGluZyB0aGUgc3RydWN0 dXJlDQpvZiB2YWx1ZXMgYXNzaWduZWQgdG8gdGhvc2UgbmFtZXMuICBXaGls ZSB1bmRlcmx5aW5nIGZpbGUgc3lzdGVtcyBtYXkNCmNob29zZSB0byBtb2Rp ZnkgYXR0cmlidXRlIHZhbHVlcywgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0 aGV5IHJlcGxhY2UNCmV4aXN0aW5nIHZhbHVlcyB3aXRoIG5ldyB2YWx1ZXMg d2hlbiB0aGUgYXR0cmlidXRlIGlzIHNldCwgYWxsb3dpbmcgYW4NCmVmZmVj dGl2ZWx5IGF0b21pYyB2YWx1ZSByZXBsYWNlbWVudCBzZXJ2aWNlLg0KDQoN CkV4aXRpbmcgSW1wbGVtZW50YXRpb25zDQoNCkEgbnVtYmVyIG9mIGV4aXN0 aW5nIGZpbGUgc3lzdGVtcyBwcm92aWRlIHN1cHBvcnQgZm9yIGV4dGVuZGVk IGF0dHJpYnV0ZXMsDQppbmNsdWRpbmcgSUJNJ3MgSFBGUywgQXBwbGUncyBI RlMrLCBhbmQgU0dJJ3MgWEZTLiAgSW4gZ2VuZXJhbCwgdGhpcyBzdXBwb3J0 DQphbGxvd3MgZm9yIHNvbWUgbnVtYmVyIG9mIG5hbWVzLCBhbmQgYWRkaXRp b25hbGx5IHZhbHVlcywgdG8gYmUgYXNzb2NpYXRlZA0Kd2l0aCBlYWNoIGZp bGUsIGFuZCBwbGFjZXMgY29uc3RyYWludHMgb24gdGhlIHNpemUgb2YgdGhl c2UgYXR0cmlidXRlcy4gIEZvcg0KZXhhbXBsZSwgaW4gSFBGUywgdGhlcmUg aXMgYSBtYXhpbXVtIG9mIDY0ayBvZiBhZGRpdGlvbmFsIG1ldGEtZGF0YSBm b3IgZWFjaA0KZmlsZSBvciBkaXJlY3RvcnkuDQoNCkEgc2ltaWxhciBidXQg ZGlzdGluY3Qgc2VydmljZSBpcyB0aGF0IG9mIG5hbWVkIGZpbGUgZm9ya3Mt LWVhY2ggZmlsZSBpcw0KaW4gZmFjdCBhIHNldCBvZiBuYW1lZCBmbGF0IGZp bGUgc3BhY2VzLCBlYWNoIGRpc3RpbmN0IGFuZCBpbmRpdmlkdWFsbHkNCmFk ZHJlc3NhYmxlIHVzaW5nIHRoZSBnZW5lcmFsLXB1cnBvc2UgZmlsZSBhY2Nl c3Mgc2VtYW50aWNzLiAgRm9yIGV4YW1wbGUsIA0KaW4gV2luZG93cyBOVCwg aXQgaXMgcG9zc2libGUgdG8gb3BlbiBzZXBlcmF0ZSBmaWxlIGRlc2NyaXB0 b3JzIGZvciBlYWNoDQpmaWxlIGZvcmssIGFuZCBzdG9yZSBsYXJnZSB2b2x1 bWVzIG9mIGluZm9ybWF0aW9uIGluIGVhY2ggZm9yay4gIEFuIGF0dHJpYnV0 ZQ0Kc2VydmljZSBpcyBub3QgaW50ZW5kZWQgdG8gcHJvdmlkZSBzdWNoIGJy b2FkIHNlcnZpY2VzLCBhbHRob3VnaCBhdHRyaWJ1dGVzDQpjb3VsZCBiZSBz dXBwb3J0IGJ5IHN1Y2ggYSBzZXJ2aWNlOiBzaW1pbGFybHksIGl0IHdvdWxk IGJlIHBvc3NpYmxlIHRvDQpleHBvc2UgZmlsZSBmb3JrcyB0aHJvdWdoIHRo ZSBhdHRyaWJ1dGUgaW50ZXJmYWNlLCBidXQgcHJvYmFibHkgbm90IGRlc2ly YWJsZQ0KZ2l2ZW4gdGhhdCB0aGUgYXR0cmlidXRlIGludGVyZmFjZSBpcyBp bnRlbmRlZCBmb3IgZGlmZmVyZW50IGZ1bmN0aW9uYWxpdHkuDQoNCg0KVm5v ZGUgSW50ZXJmYWNlIEV4dGVuc2lvbnMNCg0KVGhyZWUgbmV3IHZub2RlIGNh bGxzIHByb3ZpZGUgdGhlIG1ham9yaXR5IG9mIHJlcXVpcmVkIGFuZCBjb21t b24gYWNjZXNzDQptZXRob2RzIHRvIGV4dGVuZGVkIGF0dHJpYnV0ZXMuICBU aGVzZSBjYWxscyBhcmUgc2ltaWxhciB0byB0aGUgZXhpc3RpbmcNCmNhbGxz IGZvciBtb2RpZnlpbmcgdm5vZGUgYXR0cmlidXRlcyAoVk9QX0dFVEFUVFIg YW5kIFZPUF9TRVRBVFRSKSwgZXhjZXB0DQp0aGF0IHRoZXkgYWRkaXRpb25h bGx5IGFsbG93IHRoZSBzcGVjaWZpY2F0aW9uIG9mIGFuIGF0dHJpYnV0ZSBu YW1lLCBhcw0Kd2VsbCBhcyBhY2NlcHRpbmcgYSBnZW5lcmFsIHB1cnBvc2Ug YmluYXJ5IGJsb2IsIG5vdCBhIHNwZWNpZmljIHN0cnVjdHVyZS4NCg0KIw0K IyUgZ2V0ZXh0YXR0ciAgIHZwICAgICAgPSA9ID0NCiMNCnZvcF9nZXRleHRh dHRyIHsNCiAgICAgICAgSU4gc3RydWN0IHZub2RlICp2cDsNCiAgICAgICAg SU4gY2hhciAqbmFtZTsNCiAgICAgICAgSU5PVVQgc3RydWN0IHVpbyAqdWlv Ow0KICAgICAgICBJTiBzdHJ1Y3QgdWNyZWQgKmNyZWQ7DQogICAgICAgIElO IHN0cnVjdCBwcm9jICpwOw0KfTsNCg0Kdm9wX2dldGV4dGF0dHIgcmV0cmll dmVzIGEgbmFtZWQgYXR0cmlidXRlIChuYW1lKSBmcm9tIGEgc3BlY2lmaWMg dm5vZGUNCih2cCksIGFuZCByZXR1cm5zIGl0IHRvIGEgc2V0IG9mIGJ1ZmZl cnMgKHVpbyksIGVpdGhlciBpbiB1c2Vyc3BhY2Ugb3INCnN5c3NwYWNlLiAg VG8gYXV0aG9yaXplIHRoZSBjYWxsLCBhIGNyZWRlbnRpYWwgc3RydWN0dXJl IGlzIHByb3ZpZGVkIChjcmVkKSwNCmFzIHdlbGwgYXMgYSBwcm9jZXNzIGZv ciBoYW5kbGluZyBzY2hlZHVsaW5nIGFuZCBsb2NrcyAocCkuICBUaGlzIGNh bGwNCm1ha2VzIHRoZSBzYW1lIHVzZSBvZiB1aW8gYXMgVk9QX1JFQUQgKGFu ZCBpbiBmYWN0IG1heSBiZSBpbXBsZW1lbnRlZCBvdmVyDQpWT1BfUkVBRCBp biBzb21lIGNhc2VzKSwgcGF5aW5nIGF0dGVudGlvbiB0byB0aGUgdWlvIHJl c2lkIGFuZCBvZmZzZXQNCnZhcmlhYmxlcywgYnV0IGJvdW5kaW5nIHJldHJp ZXZhbCBhdCB0aGUgc2l6ZSBvZiB0aGUgYXR0cmlidXRlIGRhdGEgY3VycmVu dGx5DQpzdG9yZWQgaW4gdGhlIGF0dHJpYnV0ZS4gIEEgbnVsbCBjcmVkZW50 aWFsIHBvaW50ZXIgbWF5IGJlIHBhc3NlZCB0bw0KaW5kaWNhdGUgdGhhdCB0 aGUga2VybmVsLCBhbmQgbm90IGEgc3BlY2lmaWMgcHJvY2VzcywgaXMgbWFr aW5nIHRoaXMgcmVxdWVzdC4NCg0KQXMgd2l0aCByZWFkdiwgdGhlIHVpbyBy ZXNpZCBmaWVsZCB3aWxsIGJlIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUgYW1v dW50DQpvZiBkYXRhIHJlYWQuICBaZXJvIGlzIHJldHVybmVkIG9uIHN1Y2Nl c3MsIG90aGVyd2lzZSBhbiBlcnJubyB2YWx1ZSB0bw0KcmVmbGVjdCB0aGUg ZmFpbHVyZS4NCg0KTm8gbG9ja3MgbXVzdCBiZSBoZWxkIHRvIG1ha2UgdGhp cyBWT1BfIGNhbGwuDQoNClRoaXMgY2FsbCBtYXkgZmFpbCBpbiBhIG51bWJl ciBvZiB3YXlzLCBpbmNsdWRpbmcNCnJldHVybmluZyBFTk9FTlQgaWYgdGhl IGF0dHJpYnV0ZSBuYW1lIGlzIG5vdCBkZWZpbmVkLCBFSU8gaWYgYW4gSS9P DQplcnJvciBvY2N1cnMsIEVOWElPIGlmIHRoZSB1bmRlcmx5aW5nIGZpbGUg c3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgdGhlIHR5cGUNCm9mIGFjY2VzcyBy ZXF1ZXN0ZWQgKGkuZS4sIHJlYWRpbmcgYXR0cmlidXRlcyBmcm9tIGFuIHVu c3VwcG9ydGVkIHR5cGUgb2YNCmZpbGUpDQosIEVOT01FTSBpZiBtZW1vcnkg aXMgbm90IGF2YWlsYWJsZSB0byBzdXBwb3J0IHRoaXMNCm9wZXJhdGlvbiwg RURFQURMSyBpZiBsb2NrcyBhcmUgbm90IGF2YWlsYWJsZSwgRUFDQ0VTIGlm IHRoZSBjcmVkZW50aWFscw0KcGFzc2VkIGNhbm5vdCBhdXRob3JpemUgdGhl IHJlcXVlc3QsIEVGQVVMVCBpZiB0aGUgdWlvIHN0cnVjdHVyZSByZWZlcnMg dG8NCmFuIGludmFsaWQgdXNlcnNwYWNlIGFkZHJlc3MgKHNlZSBjb3B5aW4o KSksIGFuZCBFSU5WQUwgaWYgdGhlIGFyZ3VtZW50cyAoc3VjaA0KYXMgbmFt ZSBmb3JtYXR0aW5nKSBhcmUgaW52YWxpZC4gIEFkZGl0aW9uYWxseSwgRU9Q Tk9UU1VQUCBtYXkgYmUgcmV0dXJuZWQNCmlmIHRoZSBmaWxlIHN5c3RlbSBk b2VzIG5vdCBzdXBwb3J0IHRoZSByZXRyaWV2YWwgb2YgZXh0ZW5kZWQgYXR0 cmlidXRlcy4NCg0KIw0KIyUgc2V0ZXh0YXR0ciAgIHZwICAgICAgTCBMIEwN CiMNCnZvcF9zZXRleHRhdHRyIHsNCiAgICAgICAgSU4gc3RydWN0IHZub2Rl ICp2cDsNCiAgICAgICAgSU4gY2hhciAqbmFtZTsNCiAgICAgICAgSU5PVVQg c3RydWN0IHVpbyAqdWlvOw0KICAgICAgICBJTiBzdHJ1Y3QgdWNyZWQgKmNy ZWQ7DQogICAgICAgIElOIHN0cnVjdCBwcm9jICpwOw0KfTsNCg0Kdm9wX3Nl dGV4dGF0dHIgc2V0cyBhIG5hbWVkIGF0dHJpYnV0ZSAobmFtZSkgZm9yIGEg c3BlY2lmaWMgdm5vZGUgKHZwKSwNCmZpbmRpbmcgdGhlIHZhbHVlIHRvIHNl dCBpbiBhIHNldCBvZiBidWZmZXJzICh1aW8pLCBlaXRoZXIgaW4gdXNlcnNw YWNlDQpvciBzeXNzcGFjZS4gIFRvIGF1dGhvcml6ZSB0aGlzIGNhbGwsIGEg Y3JlZGVudGlhbCBzdHJ1Y3R1cmUgaXMgcHJvdmlkZWQNCihjcmVkKSwgYXMg d2VsbCBhcyBhIHByb2Nlc3MgZm9yIGhhbmRsaW5nIHNjaGVkdWxpbmcgYW5k IGxvY2tzIChwKS4gIFRoaXMNCmNhbGwgbWFrZXMgdGhlIHNhbWUgdXNlIG9m IHVpbyBhcyBWT1BfV1JJVEUgKGFuZCBpbiBmYWN0IG1heSBiZSBpbXBsZW1l bnRlZA0Kb3ZlciBWT1BfV1JJVEUgaW4gc29tZSBjYXNlcyksIHBheWluZyBh dHRlbnRpb24gdG8gdGhlIHVpbyByZXNpZCB2YXJpYWJsZSwNCmFsdGhvdWdo IG9wdGlvbmFsbHkgcmVqZWN0aW5nIG5vbi16ZXJvIG9mZnNldCBmaWVsZHMg YXMgdGhleSBtYXkgdmlvbGF0ZQ0KdGhlIHJlcGxhY2VtZW50IG5vdCBtb2Rp ZmljYXRpb24gcnVsZSBkZXNjcmliZWQgaW4gU2VtYW50aWNzLiAgQSBudWxs DQpjcmVkZW50aWFsIHBvaW50ZXIgbWF5IGJlIHBhc3NlZCB0byBpbmRpY2F0 ZSB0aGF0IHRoZSBrZXJuZWwsIGFuZCBub3QgYQ0Kc3BlY2lmaWMgcHJvY2Vz cywgaXMgbWFraW5nIHRoaXMgcmVxdWVzdC4NCg0KQXMgd2l0aCB3cml0ZXYs IHRoZSB1aW8gcmVzaWQgZmllbGQgd2lsbCBiZSB1cGRhdGVkIHRvIHJlZmxl Y3QgdGhlDQphbW91bnQgb2YgZGF0YSByZWFkLiAgWmVybyBpcyByZXR1cm5l ZCBvbiBzdWNjZXNzLCBvdGhlcndpc2UgYW4gZXJybm8NCnZhbHVlIHRvIHJl ZmxlY3QgdGhlIGZhaWx1cmUuDQoNCkFuIGV4Y2x1c2l2ZSBsb2NrIG11c3Qg YmUgaGVsZCBvbiAodnApIHRvIG1ha2UgdGhpcyBWT1BfIGNhbGwuDQoNClRo aXMgY2FsbCBtYXkgZmFpbCBpbiBhIG51bWJlciBvZiB3YXlzLCBpbmNsdWRp bmcgYWxsIGZhaWx1cmUgbW9kZXMgb2YNCnZvcF9nZXRleHRhdHRyLiAgQWRk aXRpb25hbGx5LCBpdCBpcyBwb3NzaWJsZSB0byByZWNlaXZlOiBFRkJJRyBp ZiB0aGUNCmF0dHJpYnV0ZSB2YWx1ZSBpcyBsYXJnZXIgdGhhbiBzb21lIGFk bWluaXN0cmF0aXZlIG9yIGFsbG9jYXRpb24gbGltaXQsDQpFTk9TUEMgaWYg dGhlIGRldmljZSBpcyBvdXQgb2Ygc3BhY2UgYnV0IG90aGVyd2lzZSB3b3Vs ZCBoYXZlIGFsbG93ZWQNCnRoZSBjYWxsIHRvIHN1Y2NlZWQsIGFuZCBFUk9G UyBpZiB0aGUgZmlsZSBzeXN0ZW0gaXMgbW91bnRlZCByZWFkb25seS4NCkVP UE5PVFNVUFAgbWF5IGJlIHJldHVybmVkIGlmIHRoZSBmaWxlIHN5c3RlbSBk b2VzIG5vdCBzdXBwb3J0IHRoZQ0Kc2V0dGluZyBvZiBleHRlbmRlZCBhdHRy aWJ1dGVzLg0KDQojDQojJSBybWV4dGF0dHIgICAgdnAgICAgICBMIEwgTA0K Iw0Kdm9wX3JtZXh0YXR0ciB7DQogICAgICAgIElOIHN0cnVjdCB2bm9kZSAq dnA7DQogICAgICAgIElOIGNoYXIgKm5hbWU7DQogICAgICAgIElOIHN0cnVj dCB1Y3JlZCAqY3JlZDsNCiAgICAgICAgSU4gc3RydWN0IHByb2MgKnA7DQp9 Ow0KDQp2b3Bfcm1leHRhdHRyIHJlbW92ZXMgYSBuYW1lZCBhdHRyaWJ1dGUg KG5hbWUpIGZvciBhIHNwZWNpZmljIHZub2RlICh2cCkuDQpUbyBhdXRob3Jp emUgdGhpcyBjYWxsLCBhIGNyZWRlbnRpYWwgc3RydWN0dXJlIGlzIHByb3Zp ZGVkIChjcmVkKSwgYXMgd2VsbA0KYXMgYSBwcm9jZXNzIGZvciBoYW5kbGlu ZyBzY2hlZHVsaW5nIGFuZCBsb2NrcyAocCkuICBBIG51bGwgY3JlZGVudGlh bA0KcG9pbnRlciBtYXkgYmUgcGFzc2VkIHRvIGluZGljYXRlIHRoYXQgdGhl IGtlcm5lbCwgYW5kIG5vdCBhIHNwZWNpZmljDQpwcm9jZXNzLCBpcyBtYWtp bmcgdGhpcyByZXF1ZXN0Lg0KDQpaZXJvIGlzIHJldHVybmVkIG9uIHN1Y2Nl c3MsIG90aGVyd2lzZSBhbiBlcnJubyB2YWx1ZSB0byByZWZsZWN0IHRoZQ0K ZmFpbHVyZS4NCg0KQW4gZXhjbHVzaXZlIGxvY2sgbXVzdCBiZSBoZWxkIG9u ICh2cCkgdG8gbWFrZSB0aGlzIFZPUF8gY2FsbC4NCg0KVGhpcyBjYWxsIG1h eSBmYWlsIGluIGEgbnVtYmVyIG9mIHdheXMsIGFsbCBvZiB3aGljaCBhcmUg ZG9jdW1lbnRlZCBhYm92ZQ0KZm9yIHZvcF9zZXRleHRhdHRyLiAgRU9QTk9U U1VQUCBtYXkgYmUgcmV0dXJuZWQgaWYgdGhlIGZpbGUgc3lzdGVtIGRvZXMN Cm5vdCBzdXBwb3J0IHRoZSByZW1vdmFsIG9mIGFuIGV4dGVuZGVkIGF0dHJp YnV0ZS4NCg0KDQpWRlMgSW50ZXJmYWNlcw0KDQpUbyBzdXBwb3J0IGFuIGV4 dGVuZGVkIGF0dHJpYnV0ZSBpbXBsZW1lbnRhdGlvbiBvbiBVRlMsIG9uZSBh ZGRpdGlvbmFsDQpWRlMgY2FsbCBpcyBkZWZpbmVkOg0KDQogICAgICAgIGlu dCAgICAgKCp2ZnNfZXh0YXR0cmN0bCkgX19QKChzdHJ1Y3QgbW91bnQgKm1w LCBpbnQgY21kLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY2hhciAqYXR0cm5hbWUsIGNhZGRyX3QgYXJnLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgcHJvYyAqcCkp OyANCg0KVGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBVRlMgdmZzX3F1b3RhY3Rs IGNhbGwsIGFsbG93aW5nIGZvciB0aGUgcnVudGltZQ0KY29uZmlndXJhdGlv biBvZiBleHRlbmRlZCBhdHRyaWJ1dGUgbWVjaGFuaXNtcywgaW5jbHVkaW5n IGJhY2tpbmcNCmZpbGVzIGZvciBhdHRyaWJ1dGUgc3RvcmFnZS4gIFRoZSBk ZXRhaWxzIGFyZSBVRlMtc3BlY2lmaWMsIGJ1dCB0aGVyZSBpcw0KcHJlY2Vk ZW50IGZvciBVRlMtc3BlY2lmaWMgVkZTIGNhbGxzIHRvIGNvbmZpZ3VyZSBV U0Ytc3BlY2lmaWMgYmVoYXZpb3IuDQpXaGlsZSBpbiB0aGUgbG9uZyB0ZXJt LCBpdCB3b3VsZCBwcm9iYWJseSBiZSBkZXNpcmFibGUgdG8gc3BlY2lmeSBh DQpnZW5lcmFsIG1lY2hhbmlzbSBmb3IgcHVzaGluZyBjb25maWd1cmF0aW9u IHN0YXRlIGludG8gVkZTJ3MsIHRoaXMNCm1lY2hhbmlzbSB3b3JrcyB3ZWxs IGdpdmVuIHRoZSB0YXN0LiAgVGhlIFVGUyBleHRlbmRlZCBhdHRyaWJ1dGUN CmltcGxlbWVudGF0aW9uIGJhY2tzIGV4dGVuZGVkIGF0dHJpYnV0ZXMgaW50 byB2bm9kZXMgKHVzdWFsbHkgc3RvcmVkDQppbiB0aGUgc2FtZSBmaWxlIHN5 c3RlbSwgYWx0aG91Z2ggbm90IG5lY2Vzc2FyaWx5KSwgaW5kZXhlZCBieSB0 aGUNCmlub2RlIG51bWJlciBvZiB0aGUgdm5vZGUgdG8gd2hpY2ggdGhlIGF0 dHJpYnV0ZSBpcyBhcHBsaWVkLiAgY21kIG1heQ0KY3VycmVudGx5IHRha2Ug b24gdGhlIHZhbHVlczoNCg0KI2RlZmluZSBVRlNfRVhUQVRUUl9DTURfU1RB UlQgICAweDAwMDAwMDAxDQojZGVmaW5lIFVGU19FWFRBVFRSX0NNRF9TVE9Q ICAgIDB4MDAwMDAwMDINCiNkZWZpbmUgVUZTX0VYVEFUVFJfQ01EX0VOQUJM RSAgMHgwMDAwMDAwMw0KI2RlZmluZSBVRlNfRVhUQVRUUl9DTURfRElTQUJM RSAweDAwMDAwMDA0DQoNCldoaWNoIHJlZmVyIHRvIHN0YXJ0aW5nIGFuZCBz dG9wcGluZyBleHRlbmRlZCBhdHRyaWJ1dGUgc3VwcG9ydCBvbiBhDQpwYXJ0 aWN1bGFyIFVGUyBmaWxlIHN5c3RlbSAobXApLCBhcyB3ZWxsIGFzIGVuYWJs aW5nIGFuZCBkaXNhYmxpbmcgdGhlDQpiYWNraW5nIG9mIHNwZWNpZmljIGF0 dHJpYnV0ZXMgb250byBzcGVjaWZpYyBhdHRyaWJ1dGUgZmlsZXMgKGFyZyBp cw0KY2FzdCBvZiBjaGFyICopLiAgVGhpcyBiZWhhdmlvciBtYXkgY2hhbmdl IHNvbWUsIGFuZCBhcyBzdWNoIGlzIG5vdA0KZG9jdW1lbnRlZCBoZXJlIGZ1 cnRoZXIuDQoNCg0KU3lzY2FsbHMNCg0KRWFjaCB2bm9kZSBjYWxsIGlzIGN1 cnJlbnRseSBleHBvc2VkIHZpYSBvbmUgc3lzY2FsbDoNCg0KaW50ICAgICBl eHRhdHRyX3NldF9maWxlKGNoYXIgKnBhdGgsIGNoYXIgKmF0dHJuYW1lLCBz dHJ1Y3QgaW92ZWMgKmlvdnAsDQogICAgICAgIHVfaW50IGlvdmNudCk7DQpp bnQgICAgIGV4dGF0dHJfZ2V0X2ZpbGUoY2hhciAqcGF0aCwgY2hhciAqYXR0 cm5hbWUsIHN0cnVjdCBpb3ZlYyAqaW92cCwNCiAgICAgICAgdV9pbnQgaW92 Y250KTsNCmludCAgICAgZXh0YXR0cl9ybV9maWxlKGNoYXIgKnBhdGgsIGNo YXIgKmF0dHJuYW1lKTsNCg0KRm9yIGVhY2ggY2FsbCwgcGF0aCBpcyBjb252 ZXJ0ZWQgdmlhIG5hbWVpKCkgdG8gYSB2bm9kZSwgd2l0aCBsb2NraW5nDQpm b3IgdGhlIHNlY29uZCBhbmQgdGhpcmQgY2FsbHMuICBXaGlsZSB0aGUgdm5v ZGUgaW50ZXJmYWNlIGRvZXMgbm90IHBsYWNlDQphIGxpbWl0IG9uIHRoZSBs ZW5ndGggb2YgYXR0cmlidXRlIG5hbWVzLCB0aGUgc3lzY2FsbCBtdXN0IGNv cHkgdGhlIHVzZXJsYW5kDQpzdHJpbmcgaW50byBrZXJuZWwgc3BhY2UgZm9y IHRoZSB2bm9kZSBjYWxsLCBzbyBwbGFjZXMgYSBsaW1pdCBvZiANCkVYVEFU VFJfTUFYTkFNRUxFTiBjaGFyYWN0ZXJzIG9uIHRoZSBudWwtdGVybWluYXRl ZCBzdHJpbmcsIGluY2x1ZGluZyB0aGUNCm51bCB0ZXJtaW5hdG9yLiAgSW4g dGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24sIEVYVEFUVFJfTUFYTkFNRUxF TiBpcw0KZGVmaW5lZCBhcyBOQU1FX01BWCwgd2hpY2ggaXMgMjU1IGNoYXJh Y3RlcnMuICBUaGlzIGRvZXMgbm90IHByZWNsdWRlDQppbmNyZWFzaW5nIHRo aXMgbGltaXQsIG9yIHVuZGVybHlpbmcgZmlsZSBzeXN0ZW1zIHN1cHBvcnRp bmcgaGlnaGVyIG9yDQpsb3dlciBsaW1pdHMuICBUaGUgaW92cCBhbmQgaW92 Y250IGFyZ3VtZW50cyBhcmUgc2ltaWxhciB0byB0aG9zZSBmb3VuZA0KaW4g cmVhZHYgYW5kIHdyaXRldiwgYW5kIGFyZSBjb252ZXJ0ZWQgYnkgdGhlIHN5 c2NhbGwgd3JhcHBlcnMgaW50bw0KYXBwcm9wcmlhdGVseSBmb3JtYXRlZCB1 aW8gc3RydWN0dXJlcyBmb3IgdGhlIHZub2RlIGNhbGwuDQoNClRoZSBWRlMg Y2FsbCBpcyBleHBvc2VkIHZpYSBvbmUgc3lzY2FsbDoNCg0KaW50ICAgICBl eHRhdHRyY3RsKGNoYXIgKnBhdGgsIGludCBjbWQsIGNoYXIgKmF0dHJuYW1l LCBjYWRkcl90IGFyZyk7DQoNClRoZSBtb3VudHBvaW50IGlzIHJldHJpZXZl ZCBmcm9tIHBhdGgsIHRoZSBhdHRyaWJ1dGUgbmFtZSByZWFkIGludG8gYSBr ZXJuZWwNCmJ1ZmZlciwgYW5kIHRoZSBvdGhlciBhcmd1bWVudHMgcGFzc2Vk IHN0cmFpZ2h0IHRocm91Z2guDQoNCg== --0-2036405370-945287061=:22637 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="extattr.h" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyotDQogKiBDb3B5cmlnaHQgKGMpIDE5OTkgUm9iZXJ0IE4uIE0uIFdhdHNv bg0KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAqDQogKiBSZWRpc3RyaWJ1 dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQNCiAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBw cm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucw0KICogYXJl IG1ldDoNCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0DQogKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp c2NsYWltZXIuDQogKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZv cm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAg bm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxv d2luZyBkaXNjbGFpbWVyIGluIHRoZQ0KICogICAgZG9jdW1lbnRhdGlvbiBh bmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3Ry aWJ1dGlvbi4NCiAqDQogKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5EDQog KiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUNCiAqIElNUExJRUQgV0FSUkFO VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFS VElDVUxBUiBQVVJQT1NFDQogKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVW RU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJM RQ0KICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBT UEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwNCiAqIERBTUFH RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTDQogKiBPUiBTRVJWSUNFUzsgTE9TUyBP RiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQ VElPTikNCiAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9G IExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUDQogKiBM SUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9U SEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZDQogKiBPVVQgT0YgVEhFIFVT RSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBP U1NJQklMSVRZIE9GDQogKiBTVUNIIERBTUFHRS4NCiAqDQogKgkkSWQgJA0K ICovDQoNCiNpZm5kZWYgX1NZU19FWFRBVFRSX0hfDQojZGVmaW5lIF9TWVNf RVhUQVRUUl9IXw0KDQojZGVmaW5lIEVYVEFUVFJfTUFYTkFNRUxFTglOQU1F X01BWA0KDQojaWZkZWYgS0VSTkVMDQoNCiNlbHNlIC8qIEtFUk5FTCAqLw0K DQppbnQJZXh0YXR0cmN0bChjaGFyICpwYXRoLCBpbnQgY21kLCBjaGFyICph dHRybmFtZSwgY2FkZHJfdCBhcmcpOw0KaW50CWV4dGF0dHJfc2V0X2ZpbGUo Y2hhciAqcGF0aCwgY2hhciAqYXR0cm5hbWUsIHN0cnVjdCBpb3ZlYyAqaW92 cCwNCgl1X2ludCBpb3ZjbnQpOw0KaW50CWV4dGF0dHJfZ2V0X2ZpbGUoY2hh ciAqcGF0aCwgY2hhciAqYXR0cm5hbWUsIHN0cnVjdCBpb3ZlYyAqaW92cCwN Cgl1X2ludCBpb3ZjbnQpOw0KaW50CWV4dGF0dHJfcm1fZmlsZShjaGFyICpw YXRoLCBjaGFyICphdHRybmFtZSk7DQoNCg0KI2VuZGlmIC8qIEtFUk5FTCAq Lw0KDQoNCiNlbmRpZiAvKiBfU1lTX0VYVEFUVFJfSF8gKi8NCg== --0-2036405370-945287061=:22637 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="acl_details.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: QWNjZXNzIENvbnRyb2wgTGlzdHMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CkludHJvZHVjdGlvbg0KDQpBY2Nlc3MgQ29udHJvbCBsaXN0cyBleHRlbmQg dGhlIFVOSVggZmlsZSBhbmQgZGlyZWN0b3J5IHBlcm1pc3Npb24gc2V0IHRv DQphbGxvdyBmaWxlIG93bmVycyB0byBkZWZpbmUgYWRkaXRpb25hbCByaWdo dHMgZm9yIHNwZWNpZmljIHVzZXJzIGFuZCBncm91cHMNCmZvciB0aGF0IGZp bGUuDQoNCg0KUmF0aW9uYWxlDQoNClRoZSBjdXJyZW50IFVOSVggcGVybWlz c2lvbiBtb2RlbCBpcyBxdWl0ZSBsaW1pdGVkOiBpdCBhbGxvd3MgYSBmaWxl IG93bmVyDQp0byBzcGVjaWZ5IGEgbGltaXRlZCBzZXQgb2YgcmlnaHRzIChy ZWFkLCB3cml0ZSwgZXhlY3V0ZS9sb29rdXApIG92ZXINCmEgbGltaXRlZCBz ZXQgb2YgcHJpbmNpcGFscyAoZmlsZSBvd25lciwgZmlsZSBncm91cCwgYW5k IG90aGVyKS4gIFRoaXMgcmVsaWVzDQpvbiB0aGUgc3lzdGVtIGFkbWluaXN0 cmF0b3IgdG8gbWFpbnRhaW4gZ3JvdXBzIGZvciBhbGwgcG9zc2libGUgcGVy bXV0YXRpb25zDQpvZiB1c2VycyB0aGF0IHdpc2ggdG8gc2hhcmUgZmlsZXMg d2hpbGUgbm90IG1ha2luZyB0aGUgZmlsZSBhY2Nlc3NpYmxlIHRvDQphbGwg dXNlcnMgb24gdGhlIHN5c3RlbSwgYW4gaW5hcHByb3ByaWF0ZSBhc3N1bXB0 aW9uIGluIG1vc3QgbXVsdGktdXNlcg0KZW52aXJvbm1lbnRzLiAgUE9TSVgu MWUgZGVmaW5lcyBhbiBBY2Nlc3MgQ29udHJvbCBMaXN0IGV4dGVuc2lvbiB0 aGF0DQphbGxvd3MgdXNlcnMgdG8gc3BlY2lmeSBhZGRpdGlvbmFsIHVzZXJz IGFuZCBncm91cHMgZm9yIGEgZmlsZSwgYW5kDQpyaWdodHMgZm9yIHRoZW0g b3ZlciB0aGUgZmlsZS4NCg0KVGhpcyBhbGxvd3MgYSBudW1iZXIgb2Ygc2Vj dXJpdHkgaW1wcm92ZW1lbnRzLCBib3RoIGZyb20gdGhlIHBlcnNwZWN0aXZl DQpvZiByZWd1bGFyIHVzZXJzIHNoYXJpbmcgZmlsZXMsIGFuZCBhbHNvIGZy b20gYSBzeXN0ZW1zIHBlcnNwZWN0aXZlIGFzIGl0DQphbGxvd3MgdGhlIGlu Y3JlYXNlZCB1c2Ugb2YgdGhlIHByaXZpbGVnZSBvZiBsZWFzdCBwcmluY2lw YWw6IHRoYXQgcHJvY2Vzc2VzDQpiZSBnaXZlbiBvbmx5IHRoZSByaWdodHMg dGhhdCB0aGV5IHJlcXVpcmUuICBGb3IgZXhhbXBsZSwgQUNMcyBzaW1wbGlm eQ0KbWFuYWdpbmcgZGF0YSBzaGFyaW5nIGZvciBzeXN0ZW0gc2VydmljZXMg c3VjaCBhcyBtYWlsLg0KDQpBbHRob3VnaCBBQ0xzIG1heSB2YXJ5IGluIHNl bWFudGljcyBmcm9tIGZpbGUgc3lzdGVtIHRvIGZpbGUgc3lzdGVtLCBqdXN0 DQphcyB0aGUgcHJlY2lzZSBkZXRhaWxzIG9mIGZpbGUgc2VtYW50aWNzIHZh cnksIGl0IGlzIHVzZWZ1bCB0byBkZWZpbmUNCmEgc2luZ2xlIGFuZCBjb21w cmVoZW5zaXZlIHZub2RlIGFuZCBzeXNjYWxsIGludGVyZmFjZSB0byBhbGxv dw0KY29uc2lzdGVudCBhY2Nlc3MgYWNyb3NzIGZpbGUgc3lzdGVtcy4NCg0K DQpTZXJ2aWNlcw0KDQpBcyB3aXRoIGZpbGUgc2VtYW50aWNzLCBBQ0wgc2Vt YW50aWNzIG1heSB2YXJ5IGZyb20gZmlsZSBzeXN0ZW0gdG8gZmlsZQ0Kc3lz dGVtLiAgRm9yIGV4YW1wbGUsIHBlcm1pc3Npb25zIGluIGEgZGlzdHJpYnV0 ZWQgc3lzdGVtIHN1Y2ggYXMgQUZTIG9yDQpDb2RhIG1heSBoYXZlIHF1aXRl IGRpZmZlcmVudCBpbXBsaWNhdGlvbnMgZnJvbSBwZXJtaXNzaW9ucyB1c2Vk IGxvY2FsbHkNCmluIFVGUy9GRlMuICBIb3dldmVyLCBBQ0xzIGdlbmVyYWxs eSBoYXZlIHJvdWdobHkgdGhlIHNhbWUgc3ludGFjdGljIGZvcm06DQphIGxp c3Qgb2YgcHJpbmNpcGFscywgYW5kIGZvciBlYWNoIHByaW5jaXBhbCwgYSBz ZXQgb2YgcmlnaHRzLiAgU2ltaWxhcmx5LA0KdGhlcmUgYXJlIHNpbWlsYXIg b3BlcmF0aW9ucyByZWdhcmRsZXNzIG9mIHRoZSBmaWxlIHN5c3RlbTogc2V0 dGluZyBhbmQNCnJldHJpZXZpbmcgQUNMcywgYXMgd2VsbCBhcyBjaGVja2lu ZyB0aGUgdmFsaWRpdHkgb2YgYW4gQUNMIGZvciBhIHRhcmdldA0KZmlsZSBp biBhbiBlbnZpcm9ubWVudCB3aGVyZSB0aGUgdmFsaWRpdHkgb2YgQUNMcyB2 YXJpZXMgYnkgdGFyZ2V0LiAgQXMNCnN1Y2gsIHdlIGRlZmluZSBhIHN0YW5k YXJkIHZub2RlIGludGVyZmFjZSwgc3lzY2FsbCBpbnRlcmZhY2UsIGFuZA0K c2V0IG9mIHN5bnRheCByZXF1aXJlbWVudHMgZm9yIEFDTHMuICBUaGlzIHBl cm1pdHMgaW5kaXZpZHVhbCBpbXBsZW1lbnRhdGlvbnMsDQpzdWNoIGFzIFBP U0lYLjFlIG9uIFVGUy9GRlMsIHRvIGRlZmluZSB0aGVpciBvd24gc2VtYW50 aWNzLCB5ZXQgdXNlIHRoZQ0Kc2FtZSBpbnRlcmZhY2UgYXMgb3RoZXIgaW1w bGVtZW50YXRpb25zLCBzdWNoIGFzIEFGUyBvciBDb2RhIHBlcm1pc3Npb25z Lg0KDQoNCkV4aXN0aW5nIEltcGxlbWVudGF0aW9ucw0KDQpBIG51bWJlciBv ZiBvcGVyYXRpbmcgc3lzdGVtcyBzdXBwb3J0IEFDTHMsIG9yIGhhdmUgYWRk b24gcGFja2FnZXMgdGhhdA0KcHJvdmlkZSBBQ0wgZnVuY3Rpb25hbGl0eS4g IE1hbnkgb2YgdGhlc2UgaW1wbGVtZW50YXRpb25zIGFyZSBiYXNlZCBvbiB0 aGUNClBPU0lYLjFlIGRyYWZ0LCBzb21lIHdpdGggbWlub3IgaW50ZXJmYWNl IGNoYW5nZXMuICBTb2xhcmlzIGFuZCBJUklYDQpib3RoIHN1cHBvcnQgQUNM cyBpbiB0aGUgYmFzZSBmaWxlIHN5c3RlbSB3aXRob3V0IGFkZG9uczsgaW4g dGhlIGNhc2Ugb2YNCklSSVgsIHRoZSBpbXBsZW1lbnRhdGlvbiBpcyBhbG1v c3QgZW50aXJlbHkgUE9TSVguMWUtY29tcGxpYW50LiAgSW4gdGhlDQpjYXNl IG9mIFNvbGFyaXMsIHRoZXJlIGFyZSBzaWduaWZpY2FudCBkaWZmZXJlbmNl cyBiZXR3ZWVuIHRoZSBpbnRlcmZhY2UNCmFuZCBQT1NJWC4xZS4gIExpbnV4 IGFsc28gaGFzIGFuIEFDTCBpbXBsZW1lbnRhdGlvbiwgb3JpZ2luYWxseSBj bG9zZXINCnRvIFNvbGFyaXMsIGJ1dCBub3cgbW92aW5nIGluIHRoZSBkaXJl Y3Rpb24gb2YgUE9TSVguMWUuICBBIG51bWJlciBvZg0Kb3RoZXIgb3BlcmF0 aW5nIHN5c3RlbXMgYWxzbyBzdXBwb3J0IEFDTHMsIGJ1dCB3ZXJlIG5vdCBh dmFpbGFibGUgdG8gdXMNCmZvciBpbnNwZWN0aW9uLiAgQSBjcm9zcy1wbGF0 Zm9ybSBQT1NJWC4xZSBpbXBsZW1lbnRhdGlvbiBtYWlsaW5nIGxpc3QNCmlz IGF2YWlsYWJsZSBmb3IgZGlzY3Vzc2lvbiBvZiB0aGUgUE9TSVguMWUgaW50 ZXJmYWNlIGFuZCBpdHMgcHJhY3RpY2FsDQppbXBsZW1lbnRhdGlvbiBhc3Bl Y3RzLiAgU2VuZCBlbWFpbCB0byBtYWpvcmRvbW9AY3lydXMud2F0c29uLm9y ZywgDQpjb250YWluaW5nICJzdWJzY3JpYmUgcG9zaXgxZSIuDQoNCg0KQUNM IFN5bnRheA0KDQpQT1NJWC4xZSBkZWZpbmVzIEFDTHMgYW5kIEFDTCBFbnRy aWVzLCB0aGUgY29tcG9uZW50cyBvZiBBQ0xzLiAgSW4gdGhlDQpGcmVlQlNE IFBPU0lYLjFlIEFDTCBpbXBsZW1lbnRhdGlvbiwgdGhlc2Ugb2JqZWN0IHR5 cGVzIGFyZSBiYWNrZWQgYnkNCnN0cnVjdHVyZXM6DQoNCnN0cnVjdCBhY2xf ZW50cnkgew0KICAgICAgICBhY2xfdGFnX3QgICAgICAgYWVfdGFnOw0KICAg ICAgICB1aWRfdCAgIGFlX2lkOw0KICAgICAgICBhY2xfcGVybV90ICAgICAg YWVfcGVybTsNCn07DQp0eXBlZGVmIHN0cnVjdCBhY2xfZW50cnkgICAgICAg ICphY2xfZW50cnlfdDsNCg0Kc3RydWN0IGFjbCB7DQogICAgICAgIGludCAg ICAgYWNsX2NudDsNCiAgICAgICAgc3RydWN0IGFjbF9lbnRyeSAgICAgICAg YWNsX2VudHJ5W01BWF9BQ0xfRU5UUklFU107DQp9Ow0KdHlwZWRlZiBzdHJ1 Y3QgYWNsICAgICAgKmFjbF90Ow0KDQpFYWNoIGVudHJ5IHJlZmVycyB0byBh IHByaW5jaXBhbCBuYW1lc3BhY2UgKGFjbF90YWdfdCksIGhhcw0KYSBxdWFs aWZpZXIgaW5kaWNhdGluZyB3aGljaCBwcmluY2lwYWwgaW4gdGhlIG5hbWVz cGFjZSBpcyBpbnRlbmRlZA0KKHVpZF90KSwgYW5kIGFzc2lnbnMgYSBzcGVj aWZpYyBzZXQgb2YgcmlnaHRzIChhY2xfcGVybV90KS4gIEEgc2V0IG9mDQp0 aGVzZSBlbnRyaWVzIGlzIHRoZW4gY29tYmluZWQgdG8gZm9ybSBhIGNvbXBs ZXRlIEFDTC4NCg0KUE9TSVguMWUgZGVmaW5lcyBhIGxhcmdlIGxpYnJhcnkg b2YgZnVuY3Rpb25zIGZvciBtYW5pcHVsYXRpbmcgdGhlc2UNCkFDTHMgYW5k IEFDTCBlbnRyaWVzIGluIHRoZSBhYnN0cmFjdCAod2l0aG91dCBhd2FyZW5l c3Mgb2YgdGhlIHVuZGVybHlpbmcNCkMgc3RydWN0dXJlcywgd2hlcmV2ZXIg cG9zc2libGUpLCBhcyB3ZWxsIGFzIHRoZSBtb3JlIHJlbGV2YW50IGludGVy ZmFjZXMNCmZvciByZXRyaWV2aW5nIGFuZCBzdWJtaXR0aW5nIEFDTHMgYXNz b2NpYXRlZCB3aXRoIG9iamVjdHMuICBJbiB0aGUgRnJlZUJTRA0KaW1wbGVt ZW50YXRpb24sIHRoZXNlIGludGVyZmFjZXMgYXJlIGJhY2tlZCBieSBzbGln aHRseSBtb3JlIGdlbmVyYWwNCnN5c2NhbGxzLCB3aGljaCBpbiB0dXJuIGZv cndhcmQgcmVxdWVzdHMgdG8gc2xpZ2h0bHkgbW9yZSBnZW5lcmFsIHZub2Rl DQpvcGVyYXRpb25zOyBhdCBlYWNoIHN0ZXAgYWxvbmcgdGhlIHdheSwgdGhl IHNhbWUgc3ludGF4IGZvciBBQ0xzIGlzDQpwcmVzZXJ2ZWQsIGFuZCB0aGUg Y2hlY2tpbmcgb2Ygc2VtYW50aWNzIGlzIGdlbmVyYWxseSBsZWZ0IHRvIHRo ZQ0KaW1wbGVtZW50aW5nIGZpbGUgc3lzdGVtcy4NCg0KUE9TSVguMWUgYWxz byBkZWZpbmVzIGFuIEFDTCB0eXBlLCB0byBkaXN0aW5ndWlzaCBkaWZmZXJl bnQgQUNMcyBpbiB0aGUNCmNhc2UgdGhhdCBhbiBvYmplY3QgbWF5IGhhdmUg bW9yZSB0aGFuIG9uZSBBQ0wgYXNzaWduZWQgdG8gaXQuICBQT1NJWC4xZQ0K dXNlcyB0d28gdmFsdWVzLS1vbmUgZm9yIGFjY2VzcyBBQ0xzLCBhbmQgb25l IGZvciBkZWZhdWx0IEFDTHMgb25seQ0KYXBwcm9wcmlhdGUgd2hlcmUgdGhl IG9iamVjdCBpcyBhIGRpcmVjdG9yeS4gIFRoaXMgdHlwZSBzcGVjaWZpZXIg aXMNCmV4cG9zZWQgaW4gdGhlIEFQSSwgYW5kIG5vdCBzdG9yZWQgaW4gYW4g QUNMLCBhcyBhIHBhcnRpY3VsYXIgQUNMIG1heQ0KYmUgdmFsaWQgKGFuZCBh cHBsaWNhYmxlKSBpbiBib3RoIGNhc2VzLCBhbmQgaXQgaXMgbmVjZXNzYXJ5 IHRvIGNvbXBhcmUNCkFDTHMgYXMgdGhlIHNhbWUgdHlwZSwgZXZlbiBpZiB0 aGV5IGFyZSBkaWZmZXJlbnQgImFjbCB0eXBlcyIgaW4gdGhlDQpQT1NJWC4x ZSBzZW5zZS4NCg0KSW4gdGhlIGN1cnJlbnQgVkZTIGludGVyZmFjZSwgYWNj ZXNzIHRvIGZpbGVzIGlzIHZlcmlmaWVkIGJ5IHN1Ym1pdHRpbmcNCmEgdm5v ZGUgcmVmZXJlbmNlLCBhcyB3ZWxsIGFzIGNyZWRlbnRpYWxzLCB0byBWT1Bf QUNDRVNTIChhbmQgb3RoZXJzKQ0KYW5kIGNoZWNraW5nIG9mIHJpZ2h0cyBp cyBoYW5kbGVkIHdpdGhpbiB0aGUgVkZTLiAgV2l0aCBBQ0xzLCB0aGlzIGRv ZXMNCm5vdCBjaGFuZ2UsIHNvIHRoZSB2ZXJpZmljYXRpb24gb2YgQUNMcyBp cyBnZW5lcmFsbHkgaGlkZGVuIGZyb20gbW9zdA0Ka2VybmVsIGNvZGUuICBT aW1pbGFybHksIGFzIHdpdGggYXR0cmlidXRlcywgdGhlIHN0b3JhZ2Ugb2Yg QUNMcyBpcyBsZWZ0DQp1cCB0byB0aGUgZmlsZSBzeXN0ZW06IGluIHRoZSBj YXNlIG9mIHRoZSBGcmVlQlNEIFVGUy9GRlMgaW1wbGVtZW50YXRpb24sDQph biBleHRlbmRlZCBhdHRyaWJ1dGUgbWVjaGFuaXNtIGlzIHJlbGllZCB1cG9u IHRvIHByb3ZpZGUgc3RvcmFnZSBmb3INCkFDTHMuDQoNCg0KVm5vZGUgSW50 ZXJmYWNlIEV4dGVuc2lvbnMNCg0KVGhyZWUgbmV3IHZub2RlIGNhbGxzIHBy b3ZpZGUgdGhlIG1ham9yaXR5IG9mIHJlcXVpcmVkIGFuZCBjb21tb24gYWNj ZXNzDQptZXRob2RzIGZvciBBQ0xzLCBhbHRob3VnaCB0aGUgcHJhY3RpY2Fs IGltcGxlbWVudGF0aW9uIG9mIGEgbnVtYmVyIG9mDQp0aGVzZSBvcGVyYXRp b25zIGlzIGFmZmVjdGVkIGJ5IEFDTHMgaW4gZmlsZSBzeXN0ZW1zIHRoYXQg c3VwcG9ydCBBQ0xzLg0KVGhlc2UgY2FsbHMgYXJlIHNpbWlsYXIgdG8gZXhp c3RpbmcgY2FsbHMgZm9yIG1vZGlmeWluZyB2bm9kZSBhdHRyaWJ1dGVzDQoo Vk9QX0dFVEFUVFIgYW5kIFZPUF9TRVRBVFRSKSwgZXhjZXB0IHRoYXQgaW5z dGVhZCBvZiBwYXNzaW5nIHZhdHRycywNCnRoZXNlIHJvdXRpbmVzIHBhc3Mg c3RydWN0IGFjbCdzLCBhcyB3ZWxsIGFzIGFuICJhY2wgdHlwZSIuICBXaGls ZSB0aGUNCmludGVyZmFjZSBkb2VzIG5vdCBwdXQgbGltaXRzIG9uIHRoZSBj b250ZW50cyBvZiBlaXRoZXIgdGhlIEFDTCBub3IgaXRzDQp0eXBlLCB0aGUg dW5kZXJseWluZyBpbXBsZW1lbnRhdGlvbiB3aWxsIGV2YWx1YXRlIHRoZSBz dWJtaXR0ZWQgQUNMcw0KYmFzZWQgb24gaXRzIG93biBzZW1hbnRpY3MsIGFu ZCBtYXkgcmVqZWN0IGFueSBpdCBmaW5kcyB1bmZpdC4NCg0KIw0KIyUgZ2V0 YWNsICAgICAgIHZwICAgICAgPSA9ID0NCiMNCnZvcF9nZXRhY2wgew0KICAg ICAgICBJTiBzdHJ1Y3Qgdm5vZGUgKnZwOw0KICAgICAgICBJTiBhY2xfdHlw ZV90IHR5cGU7DQogICAgICAgIE9VVCBzdHJ1Y3QgYWNsICphY2xwOw0KICAg ICAgICBJTiBzdHJ1Y3QgdWNyZWQgKmNyZWQ7DQogICAgICAgIElOIHN0cnVj dCBwcm9jICpwOw0KfTsNCg0Kdm9wX2dldGFjbCByZXR1cm5zIGFuIEFDTCBv ZiB0eXBlICh0eXBlKSBmcm9tIGEgc3BlY2lmaWMgdm5vZGUgKHZwKSwgYW5k DQpyZXR1cm5zIGl0IHRvIGFuIEFDTCBidWZmZXIgKGFjbHApIGluIHN5c3Nw YWNlLiAgVG8gYXV0aG9yaXplIHRoZSBjYWxsLCBhDQpjcmVkZW50aWFsIHN0 cnVjdHVyZSBpcyBwcm92aWRlZCAoY3JlZCksIGFzIHdlbGwgYXMgYSBwcm9j ZXNzIGZvciBoYW5kbGluZw0Kc2NoZWR1bGluZyBhbmQgbG9ja3MgKHApLiAg QSBudWxsIGNyZWRlbnRpYWwgcG9pbnRlciBtYXkgYmUgcGFzc2VkIGluIHRv DQppbmRpY2F0ZSB0aGF0IHRoZSBrZXJuZWwsIGFuZCBub3QgYSBzcGVjaWZp YyBwcm9jZXNzLCBpcyBtYWtpbmcgdGhpcw0KcmVxdWVzdC4NCg0KQXMgd2l0 aCB2b3BfZ2V0YXR0ciwgdGhlIEFDTCBzdHJ1Y3R1cmUgcG9pbnRlZCB0byBi eSBhY2xwIHdpbGwgYmUgdXBkYXRlZA0KdG8gcmVmbGVjdCB0aGUgY3VycmVu dCBzdGF0ZSBvZiB0aGUgdm5vZGUgQUNMIGluIHF1ZXN0aW9uLiAgWmVybyBp cw0KcmV0dXJuZWQgb24gc3VjY2Vzcywgb3RoZXJ3aXNlIGFuIGVycm5vIHZh bHVlIHRvIHJlZmxlY3QgdGhlIGZhaWx1cmUuDQoNCk5vIGxvY2tzIG11c3Qg YmUgaGVsZCB0byBtYWtlIHRoaXMgVk9QXyBjYWxsLg0KDQpUaGlzIGNhbGwg bWF5IGZhaWwgaW4gYSBudW1iZXIgb2Ygd2F5cywgaW5jbHVkaW5nOg0KDQpF Tk9NRU0JSW5zdWZmaWNpZW50IG1lbW9yeSB0byBmdWxmaWxsIHJlcXVlc3QN CkVBQ0NFUwlQZXJtaXNzaW9uIHdhcyBkZW5pZWQgaW4gcmVhZGluZyB0aGlz IEFDTA0KRUlOVkFMCVRoZSBhY2wgdHlwZSBwYXNzZWQgaXMgaW52YWxpZCBm b3IgdGhlIHZub2RlDQpFT1BOT1RTVVBQCVRoaXMgZmlsZSBzeXN0ZW0gZG9l cyBub3Qgc3VwcG9ydCB2b3BfZ2V0YWNsDQoNCiMNCiMlIHNldGFjbCAgICAg ICB2cCAgICAgIEwgTCBMDQojIA0Kdm9wX3NldGFjbCB7DQogICAgICAgIElO IHN0cnVjdCB2bm9kZSAqdnA7DQogICAgICAgIElOIGFjbF90eXBlX3QgdHlw ZTsNCiAgICAgICAgSU4gc3RydWN0IGFjbCAqYWNscDsNCiAgICAgICAgSU4g c3RydWN0IHVjcmVkICpjcmVkOw0KICAgICAgICBJTiBzdHJ1Y3QgcHJvYyAq cDsNCn07DQoNCnZvcF9zZXRhY2wgc2V0cyBhbiBBQ0wgb2YgdHlwZSAodHlw ZSkgZm9yIGEgc3BlY2lmaWMgdm5vZGUgKHZwKSwgZmluZGluZw0KdGhlIEFD TCB0byBzZXQgaW4gdGhlIHN0cnVjdHVyZSBwb2ludGVkIHRvIGJ5IGFjbHAg aW4gc3lzc3BhY2UuICBUbw0KZGVsZXRlIGFuIEFDTCBvZiB0aGF0IHR5cGUs IGEgbnVsbCBhY2xwIHBvaW50ZXIgbWF5IGJlIHBhc3NlZC4gIFRvDQphdXRo b3JpemUgdGhpcyBjYWxsLCBhIGNyZWRlbnRpYWwgc3RydWN0dXJlIGlzIHBy b3ZpZGVkIChjcmVkKSwgYXMgd2VsbA0KYXMgYSBwcm9jZXNzIGZvciBoYW5k bGluZyBzY2hlZHVsaW5nIGFuZCBsb2NrcyAocCkuICBBIG51bGwgY3JlZGVu dGlhbA0KcG9pbnRlciBtYXkgYmUgcGFzc2VkIGluIHRvIGluZGljYXRlIHRo YXQgdGhlIGtlcm5lbCwgYW5kIG5vdCBhIHNwZWNpZmljDQpwcm9jZXNzLCBp cyBtYWtpbmcgdGhpcyByZXF1ZXN0Lg0KDQpaZXJvIGlzIHJldHVybmVkIG9u IHN1Y2Nlc3MsIG90aGVyd2lzZSBhbiBlcnJubyB2YWx1ZSB0byByZWZsZWN0 IHRoZQ0KZmFpbHVyZS4NCg0KQW4gZXhjbHVzaXZlIGxvY2sgbXVzdCBiZSBo ZWxkIG9uICh2cCkgdG8gbWFrZSB0aGlzIFZPUCBjYWxsLg0KDQpUaGlzIGNh bGwgbWF5IGZhaWwgaW4gYSBudW1iZXIgb2Ygd2F5cywgaW5jbHVkaW5nIGFs bCBmYWlsdXJlIG1vZGVzIG9mDQp2b3BfZ2V0YWNsLiAgQWRkaXRpb25hbGx5 LCBpdCBpcyBwb3NzaWJsZSB0byByZWNlaXZlOg0KDQpFTk9TUEMJVGhlIGZp ZWwgc3lzdGVtIGlzIG91dCBvZiBzcGFjZQ0KRVJPRlMJVGhlIGZpbGUgc3lz dGVtIGlzIHJlYWRvbmx5DQoNCiMgDQojJSBhY2xjaGVjayAgICAgdnAgICAg ICA9ID0gPSANCiMNCnZvcF9hY2xjaGVjayB7DQogICAgICAgIElOIHN0cnVj dCB2bm9kZSAqdnA7DQogICAgICAgIElOIGFjbF90eXBlX3QgdHlwZTsNCiAg ICAgICAgSU4gc3RydWN0IGFjbCAqYWNscDsNCiAgICAgICAgSU4gc3RydWN0 IHVjcmVkICpjcmVkOw0KICAgICAgICBJTiBzdHJ1Y3QgcHJvYyAqcDsNCn07 DQoNCnZvcF9hY2xjaGVjayBhbGxvd3MgdGhlIGNhbGxlciB0byB2ZXJpZnkg dGhlIHZhbGlkaXR5IG9mIGFuIEFDTCAoYWNscCkNCm9mIHR5cGUgKHR5cGUp IGZvciBhIHNwZWNpZmljIHZub2RlICh2cCkuICBUaGlzIHNob3VsZCB1c3Vh bGx5IGJlIGFuDQppbmRpY2F0b3Igb2Ygd2hldGhlciBvciBub3QgdGhlIFZG UyBsYXllciB3b3VsZCByZXR1cm4gRUlOVkFMIGZvciBhDQpzaW1pbGFyIGNh bGwgdG8gdm9wX3NldGFjbCwgYW5kIGFsbG93cyB1c2VybGFuZCBwcm9jZXNz ZXMgdG8gY2hlY2sgQUNMDQp2YWxpZGl0eSBmb3IgYSBwYXJ0aWN1bGFyIHRh cmdldC4gIFRvIGF1dGhvcml6ZSB0aGlzIGNhbGwsIGEgY3JlZGVudGlhbA0K c3RydWN0dXJlIGlzIHByb3ZpZGVkIChjcmVkKSwgYXMgd2VsbCBhcyBhIHBy b2Nlc3MgZm9yIGhhbmRsaW5nIHNjaGVkdWxpbmcNCmFuZCBsb2NrcyAocCku ICBBIG51bGwgY3JlZGVudGlhbCBwb2ludGVyIG1heSBiZSBwYXNzZWQgaW4g dG8gaW5kaWNhdGUNCnRoYXQgdGhlIGtlcm5lbCwgYW5kIG5vdCBhIHNwZWNp ZmljIHByb2Nlc3MsIGlzIG1ha2luZyB0aGlzIHJlcXVlc3QuDQoNClplcm8g aXMgcmV0dXJuZWQgb24gc3VjY2Vzcywgb3RoZXJ3aXNlIGFuIGVycm5vIHZh bHVlIHRvIHJlZmxlY3QgdGhlDQpmYWlsdXJlLg0KDQpObyBsb2NrcyBtdXN0 IGJlIGhlbGQgdG8gbWFrZSB0aGlzIFZPUF8gY2FsbC4NCg0KVGhpcyBjYWxs IG1heSBmYWlsIGluIGEgbnVtYmVyIG9mIHdheXMsIGluY2x1ZGluZyBhbGwg ZmFpbHVyZSBtb2RlcyBvZg0Kdm9wX2dldGFjbC4NCg0KDQpWRlMgSW50ZXJm YWNlcw0KDQpUaGVyZSBhcmUgbm8gVkZTIGludGVyZmFjZXMgcmVsYXRpbmcg dG8gQUNMcyBjdXJyZW50bHkgZGVmaW5lZC4NCg0KDQpTeXNjYWxscw0KDQpF YWNoIHZub2RlIGNhbGwgaXMgZXhwb3NlZCB2aWEgYSBudW1iZXIgb2Ygc3lz Y2FsbHM6DQoNCmludCAgICAgYWNsX3N5c2NhbGxfZ2V0X2ZpbGUoY2hhciAq cGF0aCwgYWNsX3R5cGVfdCB0eXBlLCBzdHJ1Y3QgYWNsICphY2xwKTsNCmlu dCAgICAgYWNsX3N5c2NhbGxfc2V0X2ZpbGUoY2hhciAqcGF0aCwgYWNsX3R5 cGVfdCB0eXBlLCBzdHJ1Y3QgYWNsICphY2xwKTsNCmludCAgICAgYWNsX3N5 c2NhbGxfZ2V0X2ZkKGludCBmaWxlZGVzLCBhY2xfdHlwZV90IHR5cGUsIHN0 cnVjdCBhY2wgKmFjbHApOw0KaW50ICAgICBhY2xfc3lzY2FsbF9zZXRfZmQo aW50IGZpbGVkZXMsIGFjbF90eXBlX3QgdHlwZSwgc3RydWN0IGFjbCAqYWNs cCk7DQppbnQgICAgIGFjbF9zeXNjYWxsX2RlbGV0ZV9kZWZfZmlsZShjb25z dCBjaGFyICpwYXRoX3ApOw0KaW50ICAgICBhY2xfc3lzY2FsbF9kZWxldGVf ZGVmX2ZkKGludCBmaWxlZGVzKTsNCmludCAgICAgYWNsX3N5c2NhbGxfYWNs Y2hlY2tfZmlsZShjaGFyICpwYXRoLCBhY2xfdHlwZV90IHR5cGUsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGFjbCAqYWNs cCk7DQppbnQgICAgIGFjbF9zeXNjYWxsX2FjbGNoZWNrX2ZkKGludCBmaWxl ZGVzLCBhY2xfdHlwZV90IHR5cGUsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN0cnVjdCBhY2wgKmFjbHApOw0KDQpUaGVzZSBhcmUgdGhl IHN5c2NhbGxzIG5lY2Vzc2FyeSB0byBwcm92aWRlIHRoZSBQT1NJWC4xZSBB Q0wgbWFuaXB1bGF0aW9uDQpmdW5jdGlvbnMuICBJbiBzb21lIGNhc2VzLCBh IGJyb2RlciByYW5nZSBvZiBmdW5jdGlvbmFsaXR5IGlzIGF2YWlsYWJsZSB0 aGFuDQpyZXF1aXJlZCBmb3IgUE9TSVguMWUuDQoNCg== --0-2036405370-945287061=:22637 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="acl.h" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyotDQogKiBDb3B5cmlnaHQgKGMpIDE5OTkgUm9iZXJ0IE4uIE0uIFdhdHNv bg0KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAqDQogKiBSZWRpc3RyaWJ1 dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQNCiAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBw cm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucw0KICogYXJl IG1ldDoNCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0DQogKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp c2NsYWltZXIuDQogKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZv cm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAg bm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxv d2luZyBkaXNjbGFpbWVyIGluIHRoZQ0KICogICAgZG9jdW1lbnRhdGlvbiBh bmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3Ry aWJ1dGlvbi4NCiAqDQogKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5EDQog KiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUNCiAqIElNUExJRUQgV0FSUkFO VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFS VElDVUxBUiBQVVJQT1NFDQogKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVW RU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJM RQ0KICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBT UEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwNCiAqIERBTUFH RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTDQogKiBPUiBTRVJWSUNFUzsgTE9TUyBP RiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQ VElPTikNCiAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9G IExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUDQogKiBM SUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9U SEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZDQogKiBPVVQgT0YgVEhFIFVT RSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBP U1NJQklMSVRZIE9GDQogKiBTVUNIIERBTUFHRS4NCiAqDQogKgkkSWQgJA0K ICovDQovKiANCiAqIFVzZXJsYW5kL2tlcm5lbCBpbnRlcmZhY2UgZm9yIEFj Y2VzcyBDb250cm9sIExpc3RzDQogKi8NCg0KI2lmbmRlZiBfU1lTX0FDTF9I DQojZGVmaW5lIF9TWVNfQUNMX0gNCg0KLyoNCiAqIFBPU0lYLjFlIEFDTCB0 eXBlcw0KICovDQoNCiNkZWZpbmUgTUFYX0FDTF9FTlRSSUVTIDMyICAgIC8q IG1heGltdW0gZW50cmllcyBpbiBhbiBBQ0wgKi8NCiNkZWZpbmUgX1BPU0lY X0FDTF9QQVRIX01BWCAgICAgTUFYX0FDTF9FTlRSSUVTDQoNCnR5cGVkZWYg aW50CWFjbF90eXBlX3Q7DQp0eXBlZGVmIGludAlhY2xfdGFnX3Q7DQp0eXBl ZGVmIG1vZGVfdAlhY2xfcGVybV90Ow0KDQpzdHJ1Y3QgYWNsX2VudHJ5IHsN CglhY2xfdGFnX3QJYWVfdGFnOw0KCXVpZF90CWFlX2lkOw0KCWFjbF9wZXJt X3QJYWVfcGVybTsNCn07DQp0eXBlZGVmIHN0cnVjdCBhY2xfZW50cnkJKmFj bF9lbnRyeV90Ow0KDQpzdHJ1Y3QgYWNsIHsNCglpbnQJYWNsX2NudDsNCglz dHJ1Y3QgYWNsX2VudHJ5CWFjbF9lbnRyeVtNQVhfQUNMX0VOVFJJRVNdOw0K fTsNCnR5cGVkZWYgc3RydWN0IGFjbAkqYWNsX3Q7DQoNCi8qDQogKiBQb3Nz aWJsZSB2YWxpZCB2YWx1ZXMgZm9yIGFfdHlwZSBvZiBhY2xfZW50cnlfdA0K ICovDQojZGVmaW5lIEFDTF9VU0VSX09CSgkweDAwMDAwMDAxDQojZGVmaW5l IEFDTF9VU0VSCTB4MDAwMDAwMDINCiNkZWZpbmUgQUNMX0dST1VQX09CSgkw eDAwMDAwMDA0DQojZGVmaW5lIEFDTF9HUk9VUAkweDAwMDAwMDA4DQojZGVm aW5lIEFDTF9NQVNLCTB4MDAwMDAwMTANCiNkZWZpbmUgQUNMX09USEVSCTB4 MDAwMDAwMjANCiNkZWZpbmUgQUNMX09USEVSX09CSglBQ0xfT1RIRVINCiNk ZWZpbmUgQUNMX0FGU19JRAkweDAwMDAwMDQwDQoNCiNkZWZpbmUgQUNMX1RZ UEVfQUNDRVNTCQkweDAwMDAwMDAwDQojZGVmaW5lIEFDTF9UWVBFX0RFRkFV TFQJMHgwMDAwMDAwMQ0KDQovKg0KICogUG9zc2libGUgZmxhZ3MgaW4gYV9w ZXJtIGZpZWxkDQogKi8NCiNkZWZpbmUgQUNMX1BFUk1fRVhFQwkJMHgwMDAx DQojZGVmaW5lIEFDTF9QRVJNX1dSSVRFCQkweDAwMDINCiNkZWZpbmUgQUNM X1BFUk1fUkVBRAkJMHgwMDA0DQojZGVmaW5lIEFDTF9QRVJNX05PTkUJCTB4 MDAwMA0KI2RlZmluZSBBQ0xfUEVSTV9CSVRTCQkoQUNMX1BFUk1fRVhFQyB8 IEFDTF9QRVJNX1dSSVRFIHwgQUNMX1BFUk1fUkVBRCkNCiNkZWZpbmUgQUNM X1BPU0lYMUVfQklUUwkoQUNMX1BFUk1fRVhFQyB8IEFDTF9QRVJNX1dSSVRF IHwgQUNMX1BFUk1fUkVBRCkNCg0KI2lmZGVmIEtFUk5FTA0KDQovKg0KICog U3RvcmFnZSBmb3IgQUNMcyBhbmQgc3VwcG9ydCBzdHJ1Y3R1cmVzDQogKi8N CiNpZmRlZiBNQUxMT0NfREVDTEFSRQ0KTUFMTE9DX0RFQ0xBUkUoTV9BQ0wp Ow0KI2VuZGlmDQoNCg0KLyoNCiAqIER1bW15IGRlY2xhcmF0aW9ucyBzbyB0 aGF0IHdlIGNhbiBleHBvc2UgYWNsX2FjY2VzcyBhbGwgb3ZlciB0aGUgcGxh Y2UNCiAqIHdpdGhvdXQgd29ycnlpbmcgYWJvdXQgaW5jbHVkaW5nIHVjcmVk IGFuZCBmcmllbmRzLiAgdm5vZGUuaCBkb2VzIHRoZQ0KICogc2FtZSB0aGlu Zy4NCiAqLw0Kc3RydWN0IHVjcmVkOw0Kc3RydWN0IHByb2M7DQoNCg0KLyoN CiAqIEZ1bmN0aW9ucyBleHBvc2VkIHRvIHRoZSByZXN0IG9mIHRoZSBrZXJu ZWwvdmZzDQogKi8NCmludAlwb3NpeDFlX2FjbF9hY2Nlc3Moc3RydWN0IGFj bCAqYV9hY2wsIGludCBhX21vZGUsIHN0cnVjdCB1Y3JlZCAqYV9jcmVkLA0K CQkJICAgc3RydWN0IHByb2MgKmFfcCk7DQoNCi8qIA0KICogQ3VycmVudGx5 IGRpc2FibGVkIGR1ZSB0byBjeWNsaWMgaW5jbHVkZSBhY2wuaCByZXF1aXJl cyB2bm9kZSwgYW5kIHZpY2UNCiAqIHZlcnNhPw0KICogI2lmZGVmIF9TWVNf Vk5PREUuSA0KICogWFhYIHRoaXMgcHJldmVudHMgd2FybmluZ3MgaGl0aGVy IGFuZCB0aGl0aGVyLCBidXQgcHJvYmFibHkgaXNuJ3QgYSBnb29kDQogKiBp ZGVhLiAgSXQncyBzdXJwcmlzaW5nIGhvdyBtYW55IEZTIHNvdXJjZSBmaWxl cyBkb24ndCBpbmNsdWRlIHZub2RlLmgsDQogKiB5ZXQgZG8gaW5jbHVkZSBv dGhlciBjb2RlIGZvciBGUyBzdXBwb3J0Lg0KICovDQpzdHJ1Y3QgdmF0dHI7 DQpzdHJ1Y3Qgdm9wX2dldGFjbF9hcmdzOw0Kc3RydWN0IHZvcF9hY2xjaGVj a19hcmdzOw0Kdm9pZAlnZW5lcmljX2F0dHJfdG9fcG9zaXgxZV9hY2woc3Ry dWN0IGFjbCAqYV9hY2wsIHN0cnVjdCB2YXR0ciAqdmF0dHIpOw0KaW50CWdl bmVyaWNfdm9wX2dldGFjbChzdHJ1Y3Qgdm9wX2dldGFjbF9hcmdzICphcCk7 DQppbnQJZ2VuZXJpY192b3BfYWNsY2hlY2soc3RydWN0IHZvcF9hY2xjaGVj a19hcmdzICphcCk7DQppbnQJcG9zaXgxZV92b3BfYWNsY2hlY2soc3RydWN0 IHZvcF9hY2xjaGVja19hcmdzICphcCk7DQoNCg0KI2Vsc2UgLyogS0VSTkVM ICovDQoNCi8qDQogKiBTeXNjYWxsIGludGVyZmFjZSAtLSB1c2UgdGhlIGxp YnJhcnkgY2FsbHMgaW5zdGVhZCBhcyB0aGUgc3lzY2FsbHMNCiAqIGhhdmUg c3RyaWN0IGFjbCBlbnRyeSBvcmRlcmluZyByZXF1aXJlbWVudHMNCiAqLw0K aW50CWFjbF9zeXNjYWxsX2dldF9maWxlKGNoYXIgKnBhdGgsIGFjbF90eXBl X3QgdHlwZSwgc3RydWN0IGFjbCAqYWNscCk7DQppbnQJYWNsX3N5c2NhbGxf c2V0X2ZpbGUoY2hhciAqcGF0aCwgYWNsX3R5cGVfdCB0eXBlLCBzdHJ1Y3Qg YWNsICphY2xwKTsNCmludAlhY2xfc3lzY2FsbF9nZXRfZmQoaW50IGZpbGVk ZXMsIGFjbF90eXBlX3QgdHlwZSwgc3RydWN0IGFjbCAqYWNscCk7DQppbnQJ YWNsX3N5c2NhbGxfc2V0X2ZkKGludCBmaWxlZGVzLCBhY2xfdHlwZV90IHR5 cGUsIHN0cnVjdCBhY2wgKmFjbHApOw0KaW50CWFjbF9zeXNjYWxsX2RlbGV0 ZV9kZWZfZmlsZShjb25zdCBjaGFyICpwYXRoX3ApOw0KaW50CWFjbF9zeXNj YWxsX2RlbGV0ZV9kZWZfZmQoaW50IGZpbGVkZXMpOw0KaW50CWFjbF9zeXNj YWxsX2FjbGNoZWNrX2ZpbGUoY2hhciAqcGF0aCwgYWNsX3R5cGVfdCB0eXBl LA0KCQkJCSAgc3RydWN0IGFjbCAqYWNscCk7DQppbnQJYWNsX3N5c2NhbGxf YWNsY2hlY2tfZmQoaW50IGZpbGVkZXMsIGFjbF90eXBlX3QgdHlwZSwNCgkJ CQlzdHJ1Y3QgYWNsICphY2xwKTsNCg0KDQovKg0KICogU3VwcG9ydGVkIFBP U0lYLjFlIEFDTCBtYW5pcHVsYXRpb24gYW5kIGFzc2lnbm1lbnQvcmV0cmll dmFsIEFQSQ0KICovDQppbnQJYWNsX2NhbGNfbWFzayhhY2xfdCAqYWNsX3Ap Ow0KaW50CWFjbF9kZWxldGVfZGVmX2ZpbGUoY29uc3QgY2hhciAqcGF0aF9w KTsNCmludAlhY2xfZGVsZXRlX2RlZl9mZChpbnQgZmlsZWRlcyk7DQphY2xf dAlhY2xfZnJvbV90ZXh0KGNvbnN0IGNoYXIgKmJ1Zl9wKTsNCmFjbF90CWFj bF9nZXRfZmQoaW50IGZkLCBhY2xfdHlwZV90IHR5cGUpOw0KYWNsX3QJYWNs X2dldF9maWxlKGNvbnN0IGNoYXIgKnBhdGhfcCwgYWNsX3R5cGVfdCB0eXBl KTsNCmFjbF90CWFjbF9pbml0KGludCBjb3VudCk7DQppbnQJYWNsX3NldF9m ZChpbnQgZmQsIGFjbF90IGFjbCwgYWNsX3R5cGVfdCB0eXBlKTsNCmludAlh Y2xfc2V0X2ZpbGUoY29uc3QgY2hhciAqcGF0aF9wLCBhY2xfdHlwZV90IHR5 cGUsIGFjbF90IGFjbCk7DQpjaGFyCSphY2xfdG9fdGV4dChhY2xfdCBhY2ws IHNzaXplX3QgKmxlbl9wKTsNCmludAlhY2xfdmFsaWQoYWNsX3QgYWNsKTsN CmludAlhY2xfdmFsaWRfZmlsZShjb25zdCBjaGFyICpwYXRoX3AsIGFjbF90 eXBlX3QgdHlwZSwgYWNsX3QgYWNsKTsNCmludAlhY2xfdmFsaWRfZmQoaW50 IGZkLCBhY2xfdHlwZV90IHR5cGUsIGFjbF90IGFjbCk7DQppbnQJYWNsX2Zy ZWUodm9pZCAqb2JqX3ApOw0KDQoNCiNlbmRpZiAvKiBLRVJORUwgKi8NCiNl bmRpZiAvKiBfU1lTX0FDTF9IICovDQo= --0-2036405370-945287061=:22637-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Dec 15 16:23:52 1999 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 0FCC315451 for ; Wed, 15 Dec 1999 16:23:47 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id RAA05013; Wed, 15 Dec 1999 17:22:09 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpdAAARkaWTj; Wed Dec 15 17:22:04 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA26871; Wed, 15 Dec 1999 17:23:25 -0700 (MST) From: Terry Lambert Message-Id: <199912160023.RAA26871@usr09.primenet.com> Subject: Re: Request for objections: extended attribute and ACL interfaces To: robert+freebsd@cyrus.watson.org Date: Thu, 16 Dec 1999 00:23:24 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Dec 15, 99 02:44:21 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > As previously discussed in some detail on freebsd-arch, freebsd-security, > and posix1e, I have been working on adding support for file system access > control lists (among other things), and the supporting extended attribute > interface required to store additional meta-data in UFS and other file > systems. After a fair amount of hashing out, the interfaces seem to > please most interested parties (i.e., we've verified that the attribute > interface is sufficiently flexible for the needs of the HPFS folk, the > attribute interface provides the functionality for capabilities, acls, > mandatory access control labels, privileged code signatures, etc, and the > acl interface can handle posix.1e acls, as well as providing a mechanism > for managing other acl schemes, such as those in AFS and Coda), and we're > planning to commit these interfaces on Friday, unless objections are > raised. Please note that these are only the interfaces, not the actually > code itself, but standardizing the interfaces (especially vfs calls) makes > it easy to add the code later via kernel modules, and used in other file > systems currently provided by third parties (ARLA and Coda in particular). > > Attached please find four files, text introductions to both extended > attributes and acls, and the sys/ header files providing more detailed > information on the specifics of the interfaces. The extended descriptions > include rationale, information on implementations in other operating > systems, and the interface that descriptions and semantics. I personally have no objection to these interfaces. They seem to cover the problem space that you say that they cover, and they are at worst, harmless. [ ... ] > The UFS EA supporting code would not be committed, as it is experimental > and not well tested. Neither will the UFS ACLs over EAs support. Both of > these will be made available soon, however, and will rely on having > vnops/vfsops/syscalls assigned and available. :-) I object to these patches ever being committed. They are not truly UFS specific, and should be placed in a stacking layer so that they can be applied to any FS via normal stacking semantics. I assume that you are using reserved fields in order to do this? If so, this may justify a genberic interface to get at reserved inode data areas from an overlying layer. However, I would prefer that some other method be used, and that the existing reserved areas be partially used to move the nanosecond time on the modification date off, and fix the Y2038 problem the way that the authors of FFS intended. If there are fields left over after that, then they can be used for specific applications (like ACLs). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Dec 15 21:10:32 1999 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A4AC91537D for ; Wed, 15 Dec 1999 21:10:21 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id AAA25301; Thu, 16 Dec 1999 00:10:26 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 16 Dec 1999 00:10:25 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Terry Lambert Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Request for objections: extended attribute and ACL interfaces In-Reply-To: <199912160023.RAA26871@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry, First let me start by saying that I greatly appreciate your taking the time to send your comments--I value your feedback. Please see my comments below. > I personally have no objection to these interfaces. They seem to > cover the problem space that you say that they cover, and they are > at worst, harmless. The only functionality I'm not sure how to handle is identifying the attributes available on the file for the presence of duplication--where they back another file system visible object (such as ACLs, MAC labels, etc) then those interfaces should be used to back up the attributes. It isn't clear to me that attributes should be backed up independent of semantics available to interpret them, as they will most often be used for file system services where restoring them and associating them with the same file may not make sense, nor even be possible given the rights and functionality associated with what they back. I am comfortable not defining that behavior just now, and waiting to see what applications require it. I can also conceive of write-only attributes, etc. > > The UFS EA supporting code would not be committed, as it is > > experimental and not well tested. Neither will the UFS ACLs over > > EAs support. Both of these will be made available soon, however, > > and will rely on having vnops/vfsops/syscalls assigned and > > available. :-) > > I object to these patches ever being committed. They are not truly > UFS specific, and should be placed in a stacking layer so that they > can be applied to any FS via normal stacking semantics. Whether or not these changes are committed is a matter, of course, for general debate and I welcome any constructive discussion of both the general architecture of the changes, and my specific implementation. Onne of the goals of adding the interfaces first was to provide a development framework for those needing to rely on the functionality, and to make them available so that consumers of these interfaces could determine if the interfaces and semantics met their needs. First, I'd like to address the issue of whether or not extended attributes and ACLs should be made available as a stacked layer service, or whether they should be in the base file system. As you read in my detailed documentation of these services, there are a number of existing implementations that we can reference in looking for advantages and disadvantages to various approaches. The previous implementations that I have in mind are the following: - Trusted IRIX XFS: extended attributes for supporting extended security labels, including ACLs, MAC labels, capabilities. - IBM HPFS: general purpose named, extended attributes, used to store program information, access control attributes, icons, etc. - Transarc AFS: per-directory ACLs - CMU Coda: per-directory ACLs - Solaris UFS: per-file ACLs - Linux ACL extensions: per-file ACLs - Microsoft NTFS: named file forks - UDF: named file forks - Apple HFS+: named file forks - Jeff Weidner's EA + ACL layers One of the first things that becomes clear, as you allude to below, is that in most cases, access control information for file systems is considered an integral part of the file system meta-data. The only exception in the list above, other than those that don't store access control information at all, is HPFS, which uses extended attributes for this purpose. ACLs in most of these have different properties: they refer to different principal namespaces (UFS: local uids and gids; AFS: centrally administered viceids mapped to Kerberos principals, ...) Similarly they have different semantics: AFS applies ACLs to directories only, and not files. The set of permissions is far more detailed than UFS, and does not rely on an "owner". On the other hand, Solaris and Linux ACLs are mapped one per file, and two in the case of directories, and attempt to closely follow the existing POSIX permission set, and are strictly a superset of the base POSIX uid/gid + permissions concept. As I describe in my documents, and implement, the only common feature seems to be the syntax of ACLs, which is generally consistent in assigning a mask of rights to a numerically identified principal. Given that the goal of VFS is to represent that which is common between file systems, it makes sense to expose the syntax, and not the semantics, of ACLs. Access control choices are made in the file system itself, or as you point out, in a layer. Layering allows common semantics to be applied in a specific area of functionality, over what are potentially file systems with quite different semantics: for example, you can imagine composing a caching layer over a combination of NFS and Coda; you could similarly imagine composing namespace extensions and a base file system to expand or restrict naming capabilities. You suggest layering access control extensions over UFS, which is indeed possible (Jeff Weidner made a first pass at this). However, I would argue that this may not be desirable; in fact, you appear to agree that extended access controls might be useful in the base UFS as you suggest using spare fields. It's useful to note that if you're willing to go entirely to a new access control mechanism, you can reclaim at least 8 bytes, as you no longer need the file owner and group. You can also grab at the permission bits, but that's probably not worth it. As such, my opinion is that ACLs are not something that should be introduced via a layer--I find especially concerning the limitations of layering in terms of persistent state consistency management between layers. For example, in the event of a system failure (power loss, if you will), not only must you keep both layers individual consistent (say, two UFS file systems, one the real files, one backing the ACLs), but you must also keep the two consistent with one another. In my mind, it is not acceptable to permit divergence of access control data and other file system meta-data. Of course, this is already a problem under UFS, but only becomes more so without transactional support on a per-file system basis, and then transactional consistency mechanisms between layers (nested transactions, perhaps?) At the very least, the layers must be resynchronized. I'm also concerned with the assignment of vnode backing objects between layers: is there a consistent and generalized way to map objects in one layer to objects in the layer below? When no persistent state is involved, it's fairly straight forward to simply apply appropriate changes to the layers in parallel, and dynamically construct node objects in the top layer to map to active nodes in the bottom layer, via the name lookups, etc. But when you have persistent state cross-session in both layers, it becomes more difficult. This is the same problem that was discussed on -hackers recently: Coda and AFS do not provide "inode number" semantics for the value exposed via vop_getattr in the vattr field: how to identify two instances of the same object. It does not make sense, for example, to tag the top layer object (an ACL, say) with the dev_t and inode_t of the bottom layer object, as those are fs-specific values with semantics that may differ from the extremely strong POSIX semantics, which require that over the life time of an object, that specific inode_t and dev_t, in combination, uniquely identify the object. In the context of a distributed file system this makes little sense, and is hard for systems such as Coda and AFS (96 bit file ids, or fids) to emulate without excessive cost. They use a hash to hack around this requirement, but in operating systems that uniquely identify objects in kernel by unique dev_t and inode_t (Linux, for example) you see all hell break loose when a collision occurs. As BSD uses vnode pointers to verify object uniqueness in kernel (leaving aside aliasing, another issue), this is not a problem. Some userland applications, such as tar, attempt to use the unique inode_t to check for the same file, but this is known not to work in AFS, etc, and should not work. A samefile() call has been suggested, comparing two fd's, but is not implemented. But just as the userland application should not determine based on these effectively non-unique numbers the mapping between fs objects, neither should a stacked layer. I assume this issue has been addressed, possibly by assume parallel naming structures (i.e., apply all name operations to the top layer as to the bottom?), but do not know how this was done. I'd imagine this would make it easy to create layers that just maintain general fs data in the root of the file system, but hard to create layers that attach object-specific data, such as attributes, to objects in lower layers. Especially in the context of a service such as hard links, or when an ACLfs is layered over a namespace built of different file system services (say, AFS and UFS), or a transient service, such as procfs. Some of this can be solved by upcalls and better synchronization, but in many cases such synchronization is not possible or feasible. Leaving aside these concerns about the feasibility of stacking as a mechanism for mapping attributes onto objects, I recognize that layering/stacking is extremely useful functionality, and understand that significant work is underway to remedy locking problems present in the current implementation, and look forward to this service being available. > I assume that you are using reserved fields in order to do this? > If so, this may justify a genberic interface to get at reserved > inode data areas from an overlying layer. However, I would > prefer that some other method be used, and that the existing > reserved areas be partially used to move the nanosecond time > on the modification date off, and fix the Y2038 problem the > way that the authors of FFS intended. If there are fields left > over after that, then they can be used for specific applications > (like ACLs). Actually, this is not the technique I am using. I followed the lead of the quota file system code, storing attributes in backed vnodes, indexed by inode on a per-fs basis. This implementation method is subject to debate, but seems to work well as it stands. As with Quotas, I provide vfs call, extattrctl, which allows an appropriately privileged user process to pass a vnode reference (via a file path, probably in the same fs as the attributes, but not necesarily) down to UFS for a source of backing data. This requires one backing file per attribute per fs. Again, similar to the quota implementation supporting different named quotas, a chain of vnodes is maintained, each with a name identifying which attribute it corresponds to. When an attribute is retrieved or submited, the inode number (acceptable to use since we're within the UFS layer where we know this information does uniquely identify the file) is mapped to a location in the file where attribute data may be found. This file is usually a sparse file, as attributes are not always applied to all files; in fact, given that POSIX.1e ACLs are a superset of the permission behavior, it is expected that many files will not have extended ACLs. The attribute file stores various other pieces of meta-data about the attributes, including whether they are defined for a particular inode (as with environment variables, it's possible to have an attribute be undefined, or defined but with no contents, and they should be distinguishable). These implementation choices impose a number of semantic differences from other extended attribute implementations. For example, unlike HPFS, there is a fixed maximum size per-attribute, but this maximum is independent of other attribute storage on a particular file. In HPFS, the total size of the attributes is not permitted to exceed 64k. Also, attributes must be initialized and configured by an appropriately privileged entity, most likely root in the default BSD security environment, and at that initialization time access rights are set, maximum sizes, etc. Arbitrary attributes may not be defined, in this environment. These differences in semantics suggest, as with other file system behavior, that the generalized properties be exposed in the VFS via vop_ calls, but that individual file systems can behave differently. In this manner, attributes are like all other file system behaviors: optimized for a particular environment, and the needs of the designer. If layering worked correctly, and supported an adequate mechanism for mapping ACLs onto objects consistently between layers, I would be willing to consider reimplementing ACLs as a layer. Similarly, I suppose those would be possible for attributes. But I object to the idea that extended attributes and ACLs are not specific to UFS: any individual implementation will be optimized and designed to solve particular needs, in a particular way, and based on the filestore properties. In Linux, for example, it was observed that ACLs are often the same across a number of files: as a result, they allocate ACL blocks in the file store, and refcount them, permitting files with the same ACLs to point to the same ACL blocks. They do this probabalistically, of course, as they cannot keep all ACLs in memory, but it's a useful,file-system specific optimization. In Solaris, different choices were made: they choose to use "shadow inodes" and allow ACLs of (effectively) unlimited length. HPFS, because there is available space in the Fnode, the designers initially store extended attributes there, and then overflow into a block run when additional space is required. The designers of HPFS anticipated that the base attributes would need fast access, but that additional attributes were desirable given their intent to move towards an object-oriented file system environment. This is also perfectly acceptable as a local file system optimization that is HPFS-specific. In NTFS, a generic named file fork service is provided, where the forks are complete address spaces with the full flat-file semantic. This could be viewed as an extended attribute, although as I describe in my document my feeling is this is not appropriate to do :-). The Apple file system supports only specific forks: these are legitimate local design choices, that while they could be provided as file system layers, made sense not to. My personal feeling on the file fork issue is that we already have a mechanism to provide multiple complete address spaces under a path, each with a different name. We even allow this to be done recursively. It's called a directory tree, and the address spaces are known as files. :-) As such, I disagree with the assertion that it is inappropriate to add new services to existing file stores: to fail to do so would be to fail to pay attention to changing requirements. While layering is a useful extensibility mechanism, it has failed to deliver, and may continue to fail to deliver. By keeping ACL and Extended Attribute data within a single file system, we allow that file system to provide consistency guarantees not provided in the extisting layering model. You can imagine transactional and logging file systems maintaining versioning information on the attributes themselves, as in fact I believe XFS can do. While you could theoretically extend layering interfaces to provided nested transactional semantics, theres the important question of whether this is really feasible, and given the added complexity, entirely desirable. Given a sufficently powerful layering mechanism, many things are possible. If there were any easier way to provide ACL, MAC, and Capability support under UFS, the chances are I would have done it, but I didn't seem to find one. Whether or not the UFS extended attribute code ends up being committed is a decision I don't think anyone is ready to make yet, given that I'm probably the only person who has seen them. :-) Either way, the services are required in a number of environments in the immediate future. In the short and long term, having both the interfaces defined for these services will facilitate a lot of further development, including improved support for HPFS, and the ability to introduce features associated with the trusted extensions operating system extensions in POSIX.1e. Robert Watson Research Scientist, TIS Labs at Network Associates To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 16 10:50:11 1999 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1046114DD4 for ; Thu, 16 Dec 1999 10:50:03 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA27995; Thu, 16 Dec 1999 13:50:16 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 16 Dec 1999 13:50:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: David Wolfskill Cc: freebsd-fs@freebsd.org Subject: Re: Request for objections: extended attribute and ACL interfaces In-Reply-To: <199912161545.HAA13748@pau-amma.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 16 Dec 1999, David Wolfskill wrote: > >Date: Thu, 16 Dec 1999 00:10:25 -0500 (EST) > >From: Robert Watson > >Reply-To: Robert Watson > > [OK; if you insist. Was going to reply to -fs, but the Reply-To: > trumped that. -- dhw] David, My intent was not to reject responses to the list, but instead have the response go to my FreeBSD mailbox instead of my primary inbox :-). Reply-to isn't well defined, however, so different mailers do different things. I've CC'd this response to the list. > >First, I'd like to address the issue of whether or not extended attributes > >and ACLs should be made available as a stacked layer service, or whether > >they should be in the base file system. As you read in my detailed > >documentation of these services, there are a number of existing > >implementations that we can reference in looking for advantages and > >disadvantages to various approaches. The previous implementations that I > >have in mind are the following: > > >.... > .... > > In the case of RACF (IBM's product that implements SAF; there are other > products, from other vendors, that also do implement it, though probably > in different ways; I never used them), the ACLs are maintained in a > "database" -- thus, entirely separate from the file system > implementation itself. I believe that HP/UX does this, upcalling to a userland database process to maintain security tags for files. It has both advantages and disadvantages. Given functional layering, it's easy to imagine a layer that upcalls to a database for property changes, including extended capabilities, etc. > One of the more interesting aspects of the use of a separate database > for the ACLs (called "profiles" in RACF) is that they permitted a > certain amount of "wildcarding" (or "globbing") -- referred to as > "generic profiles" in RACF. > > This was handy, in that one could establish a baseline ACL, and then > override it with more specific ACLs as required. > > In thinking about extending this to a hierarchical file system, it would > be analogous to specifying an ACL based on a (possibly globbed) > pathname. And I find it of some interest that one could well have > multiple pathnames that point to the same inode (and thus, to the same > data), but since the paths are different, it could be possible to have > different ACLs that apply. > > I find this similar to the notion that an executable could be exec()ed > via different pathnames, and might alter its behavior in accord with the > pathname by which it was invoked: yes, it complicates things to some > extent, but it provides a level of flexibility that is appealing (well, > to me). (Of course, in order for this to be at all rational, it would > need to only work with hard links, and the link() call would need to > check the ACL for the subject of the link, to verify that the link() is > to be permitted. Well, *maybe* there's a way for a symlink to work, but > I see that path fraught with danger, especially since the subject of a > symlink doesn't need to exist ahead of time... so someone could create a > "stealth" symlink to bypass a (subsequently-instantiated) ACL.) This actually sounds a lot like the Trusted Path Execution (TPE) patches made available by (I forget who, unfortunately) a while ago. Essentially, it allows only certain paths to delegate rights, and associates capabilities with those paths, as opposed to with the objects themselves, at execution. This is an interesting and useful idea, but indeed is quite semantically different from the notion of per-file capabilities and ACLs. This isn't to say it isn't useful, but because the VFS file semantics support relatively easy namespace manipulation, especially of the name provided to binaries executing, the executables have to be very careful what they do with their rights, and with permissions on all directories leading to the executables. This namespace-based ACL allocation to objects would, however, make a lot of sense as a file system layer with static data--more sense than the attributes/acl approach as imlpemented in a layer as Terry suggests. Because the ACLs are tied to lookups as opposed to objects, there is no correctness or inter-layer consistency factor to consider. However, it's certainly not POSIX :-), and gets rid of the flexibility to relocate things regardless of names -- for example, moving a user's home directory from /home/user to /homea/user does interesting things to ACLs in effect for the space. With ACLs bound to objects, this is never a problem. > But in general, the idea of *not* requiring a one-to-one correspondence > of ACL to object protected would seem to be a big win. Yes--if only from a space optimization perspective. One simplification POSIX.1e provides us with is that objects do not have to have ACLs--they can just have permissions. Another is that namespace recursive permissions are used--as with permissions today on directories, ACLs in directories leading to the file provide some sorts of masking of object availability. If you throw out hard links, both today's directory permissions and tomorrow's ACLs become far more consistent in behavior. > Anyway, I can certainly go into additonal levels of detail about what I > recall of RACF; I used to install it & write MVS system exits that used > it. Once layering works adequately, it would be interesting to write a layer that provides this service. I guess an obvious question is how you represent ACLs for submission to the layer: right now setting the ACL either occur on a file descriptor for the directory, or by a pathname, from the perspective of userland. These are both converted to vnodes for submission to the FS, and the ACL is passed in. It's not clear you can distinguish the namei() used by acl setting from the namei() used for file opening, so you'd probably need a new interface; alternatively, we hide your new form of ACL in an ACL structure and apply it to the directory that is the root of the region covered by the ACL. A question that comes to mind is how you deal with file system boundaries and mountpoints--I guess the safest assumption is that the layer covers the whole namespace, and you just have a submit_acl(root, aclstring) where aclstring is the glob. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 16 14:46: 6 1999 Delivered-To: freebsd-fs@freebsd.org Received: from shell.xecu.net (shell.xecu.net [208.241.7.3]) by hub.freebsd.org (Postfix) with ESMTP id 2F571152B4; Thu, 16 Dec 1999 14:45:49 -0800 (PST) (envelope-from andy@xecu.net) Received: from localhost (andy@localhost) by shell.xecu.net (8.9.1/8.9.1) with ESMTP id RAA18475; Thu, 16 Dec 1999 17:45:44 -0500 (EST) X-Authentication-Warning: shell.xecu.net: andy owned process doing -bs Date: Thu, 16 Dec 1999 17:45:43 -0500 (EST) From: Andy Dills To: freebsd-questions@freebsd.org Cc: freebsd-fs@freebsd.org Subject: Maxtor 40GB HD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org After fooling around with my problem (trying to create a 40GB fs), I've found something strange. It feels like there is a hard limit somewhere between 27 and 27.5 GB. If I make a FS 27.5 GB large, the newfs will fail. If it's 27 GB, it works. I don't think it's a geometry problem, as it doesn't matter if it's the last 27 GB of the disk or the first 27 GB; both work. But, regardless of position on the disk, I can't create a FS larger that this limit that is somewhere between 27 and 27.5 GB. I'm guessing the limit is number of sectors/fs, but it's easier to type in bytes than in sectors. This is backed up by somebody who emailed me stating that with their 27.5 GB drive, they had to leave off the last couple of sectors to get it to work. So, is this a bug, a kernel config, or anything you recognize? And, anything I can do to fix it? Thanks, Andy ---------------------------------------------------- Andy Dills 301-682-9972 Network Administrator Fax 301-695-4060 Xecunet, LLC www.xecu.net ---------------------------------------------------- Dialup * Webhosting * E-Commerce * High-Speed Access To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 16 18: 4:37 1999 Delivered-To: freebsd-fs@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 30BC8156A6 for ; Thu, 16 Dec 1999 18:04:27 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id TAA17515; Thu, 16 Dec 1999 19:03:56 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp05.primenet.com, id smtpdAAAESailI; Thu Dec 16 19:03:55 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id TAA08405; Thu, 16 Dec 1999 19:04:17 -0700 (MST) From: Terry Lambert Message-Id: <199912170204.TAA08405@usr07.primenet.com> Subject: Re: Request for objections: extended attribute and ACL interfaces To: robert+freebsd@cyrus.watson.org Date: Fri, 17 Dec 1999 02:04:17 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-fs@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Dec 16, 99 00:10:25 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Terry, > > First let me start by saying that I greatly appreciate your taking the > time to send your comments--I value your feedback. Please see my comments > below. > > > I personally have no objection to these interfaces. They seem to > > cover the problem space that you say that they cover, and they are > > at worst, harmless. > > The only functionality I'm not sure how to handle is identifying the > attributes available on the file for the presence of duplication--where > they back another file system visible object (such as ACLs, MAC labels, > etc) then those interfaces should be used to back up the attributes. It > isn't clear to me that attributes should be backed up independent of > semantics available to interpret them, as they will most often be used for > file system services where restoring them and associating them with the > same file may not make sense, nor even be possible given the rights and > functionality associated with what they back. I am comfortable not > defining that behavior just now, and waiting to see what applications > require it. I can also conceive of write-only attributes, etc. The reason I said "harmless" is rather deeper. The Heidemann framework supports the ability to add VOP's to an existing system. FreeBSD doesn't currently support this, but it could be fixed to do so, simply by making *vfs_op_descs[] a pointer reference, and reallocating it as needed in order to grow the descriptor list using loaded descriptors. For this to work safely, a secondary step of reallocating the instance structures larger for exisiting VFS instances would do the trick, such that the new VOPs didn't dereference off the end of the instance structures, should you call them on an existing VFS. To get rid of the overhead of the pointer dereference, you could simplify the descriptor calls. The easiest way to do this would be to sort the decriptors at instance time, to ensure that all descriptors in all VFS instances were in a particular order, and then use an integer index to dereference them, instead of having to dereference them through both *vfs_op_descs[] and the reverse lookup mechanism. This should also result in a speed improvement, anyway, compared to what is currently done. System calls can also be loaded. At this point, there doesn't seem to be any reason to statically put this stuff in the kernel, but at least it's harmless. > > > The UFS EA supporting code would not be committed, as it is > > > experimental and not well tested. Neither will the UFS ACLs over > > > EAs support. Both of these will be made available soon, however, > > > and will rely on having vnops/vfsops/syscalls assigned and > > > available. :-) > > > > I object to these patches ever being committed. They are not truly > > UFS specific, and should be placed in a stacking layer so that they > > can be applied to any FS via normal stacking semantics. > > Whether or not these changes are committed is a matter, of course, for > general debate and I welcome any constructive discussion of both the > general architecture of the changes, and my specific implementation. Onne > of the goals of adding the interfaces first was to provide a development > framework for those needing to rely on the functionality, and to make them > available so that consumers of these interfaces could determine if the > interfaces and semantics met their needs. Clearly, it is good to have a reference implementation; however, I believe that it's possible to have the entire framework be dynamically loadable. My objection to commiting UFS specific ACL patches is not merely that they potentially consume fields that are necessary to solve the Y2038 issue (and were intended for that purpose), by displacing the fields that we would use to allow (IMO, unnecessary: think monoclock) nanosecond resolution on the one field that could be argued to need it, mtime. Further, it must render the fields that it uses unavailable to future researchers. I think it's also significant that, with these changes mandatorily in UFS, the supporting code, which I've demonstrated above could be rendered dynamically loadable, must instead become part of the base kernel definition. > First, I'd like to address the issue of whether or not extended attributes > and ACLs should be made available as a stacked layer service, or whether > they should be in the base file system. As you read in my detailed > documentation of these services, there are a number of existing > implementations that we can reference in looking for advantages and > disadvantages to various approaches. The previous implementations that I > have in mind are the following: > > - Trusted IRIX XFS: extended attributes for supporting extended security > labels, including ACLs, MAC labels, capabilities. > - IBM HPFS: general purpose named, extended attributes, used to store > program information, access control attributes, icons, etc. > - Transarc AFS: per-directory ACLs > - CMU Coda: per-directory ACLs > - Solaris UFS: per-file ACLs > - Linux ACL extensions: per-file ACLs > - Microsoft NTFS: named file forks > - UDF: named file forks > - Apple HFS+: named file forks > - Jeff Weidner's EA + ACL layers I would add VXFS (Veritas), FILES-11 (DEC VMS), NXFS (Novell -- mine, from the NetWarefor UNIX product), NWFS (Novell -- NetWare [mine]), and the object file system in the "Choices" OS from the University of Kentucky, which adds ACLs through object inheritance. I don't have a comprehensive list handy, and unfortunately, won't be able to look for one until after the first of the year. > One of the first things that becomes clear, as you allude to below, is > that in most cases, access control information for file systems is > considered an integral part of the file system meta-data. The only > exception in the list above, other than those that don't store access > control information at all, is HPFS, which uses extended attributes for > this purpose. ACLs in most of these have different properties: they > refer to different principal namespaces (UFS: local uids and gids; AFS: > centrally administered viceids mapped to Kerberos principals, ...) > Similarly they have different semantics: AFS applies ACLs to directories > only, and not files. The set of permissions is far more detailed than > UFS, and does not rely on an "owner". On the other hand, Solaris and > Linux ACLs are mapped one per file, and two in the case of directories, > and attempt to closely follow the existing POSIX permission set, and are > strictly a superset of the base POSIX uid/gid + permissions concept. As I > describe in my documents, and implement, the only common feature seems to > be the syntax of ACLs, which is generally consistent in assigning a mask > of rights to a numerically identified principal. I'd also suggest that it might be best to place ACLs in an EA, and merely support EAs in the storage layer, reserving ACL management and operation for a semantic layer. > Given that the goal of VFS is to represent that which is common between > file systems, it makes sense to expose the syntax, and not the semantics, > of ACLs. Access control choices are made in the file system itself, or as > you point out, in a layer. Layering allows common semantics to be applied > in a specific area of functionality, over what are potentially file > systems with quite different semantics: for example, you can imagine > composing a caching layer over a combination of NFS and Coda; you could > similarly imagine composing namespace extensions and a base file system to > expand or restrict naming capabilities. You suggest layering access > control extensions over UFS, which is indeed possible (Jeff Weidner made a > first pass at this). However, I would argue that this may not be > desirable; in fact, you appear to agree that extended access controls > might be useful in the base UFS as you suggest using spare fields. It's > useful to note that if you're willing to go entirely to a new access > control mechanism, you can reclaim at least 8 bytes, as you no longer need > the file owner and group. You can also grab at the permission bits, but > that's probably not worth it. It may be worthwhile to do this, if you displace existing controls into the ACLs. As far as using spare fields, my suggestion is to have a "VOP_SPARE" or similar mechanism for getting the size of spare fields, and then manipulating them if they are sufficiently large. This would allow you to use your ACLs on any VFS type that had spare fields in the inode, not just UFS. One issue on layering: FFS is actually composed of FFS and UFS VOP descriptors. It would be very easy to define a new local media VFS type that replaced the VOP descriptors which had to be modified in order to support ACLs with the modified VOP descriptors, leaving FFS more or less intact. One issue that seems especially pertinent to me is that, unless you have modelled the FFS dependency graph, and then written the necessary metadata resolvers (like Kirk had to, in order to do the work he did), then it seems to me that putting the code in the base system will break soft updates. > As such, my opinion is that ACLs are not something that should be > introduced via a layer--I find especially concerning the limitations of > layering in terms of persistent state consistency management between > layers. For example, in the event of a system failure (power loss, if you > will), not only must you keep both layers individual consistent (say, two > UFS file systems, one the real files, one backing the ACLs), but you must > also keep the two consistent with one another. In my mind, it is not > acceptable to permit divergence of access control data and other file > system meta-data. Of course, this is already a problem under UFS, but > only becomes more so without transactional support on a per-file system > basis, and then transactional consistency mechanisms between layers > (nested transactions, perhaps?) At the very least, the layers must be > resynchronized. This is one of the reasons that I argued that soft updates should have been written with the dependency graph model intact, and then registered inter-node resolvers (using exactly the same data structures that are currently used, BTW) at the time that the VFS was instanced. This would allow externalization of the head and tail ends of the graph, which would allow you to do soft updates between layers, or even export a transactioning interface (BEGIN, COMMIT/ABORT) to user space. I will personally work on this once the soft updates copyright changes to allow me to do a derivative work without copyright infringement or intellectual property worries; I discussed the issue at length with both Ganager and Patt after their paper was first published. Consistancy of a layer storing metadata in an underlying layer is rather trivial, even without this, as the soloution is well known to all: all metadata writes must be ordered, and committed to stable storage before the next metadata write can proceed. I think that you could do ACLs easily in a folding layer that simply called VOP_SYNC() on the ACLs vnode. This takes a bit of a performance hit, but would be worthwhile. Give a hook into the soft updates metadata dependency resolution clock, it becomes not hit at all, relative to the non-stacking implemetnation. I admit, you could design the data structures wrong such that you would not have deterministic recovery. I think this is easily fixed by simply adding a timestamp, and not removing the previous value (by zeroing the timestamp) until the inode metadata is flushed. Recovery could be rolled forward or backward depending the on the comparison of the newest time stamp in the ACL file to the time on the inode to which the ACL applies. > I'm also concerned with the assignment of vnode backing objects between > layers: is there a consistent and generalized way to map objects in one > layer to objects in the layer below? When no persistent state is > involved, it's fairly straight forward to simply apply appropriate changes > to the layers in parallel, and dynamically construct node objects in the > top layer to map to active nodes in the bottom layer, via the name > lookups, etc. But when you have persistent state cross-session in both > layers, it becomes more difficult. This is the same problem that was > discussed on -hackers recently: Coda and AFS do not provide "inode number" > semantics for the value exposed via vop_getattr in the vattr field: how to > identify two instances of the same object. It does not make sense, for > example, to tag the top layer object (an ACL, say) with the dev_t and > inode_t of the bottom layer object, as those are fs-specific values with > semantics that may differ from the extremely strong POSIX semantics, which > require that over the life time of an object, that specific inode_t and > dev_t, in combination, uniquely identify the object. The short answer is that there _is_ an object alias problem. The longer answer is that the fix for this problem is obvious, and that there is a workaround that uses read/write in the underlying FS to provide VOP_{GET|PUT}PAGES() functionality, to make stacking work in the current kernel, without the vmobject_t aliases problem that you would otherwise suffer. At worst, you could use the workaround, for which source code already exists and can easily be grabbed and inserted. > In the context of a distributed file system this makes little sense, and > is hard for systems such as Coda and AFS (96 bit file ids, or fids) to > emulate without excessive cost. This argument is really non-applicable, because of the above, since stacking works. If the argument is association of data with metadata, namespace folding is probably the correct approach (files are directories, with file data in the file "data" in the directory named for the file, and ACLs in the file "ACL" in the directory named for the file). This speaks to your object attachment argument. In addition, you could expose the underlying VFS, and then use a standard UNIX backup tool, such as tar, to back it up, _without_ needing to teach the tool about ACLs. I think this represents a significant advantage over an inode-embedded approach, which requires you to get all new (non-interoperable) tools. > Leaving aside these concerns about the feasibility of stacking as a > mechanism for mapping attributes onto objects, I recognize that > layering/stacking is extremely useful functionality, and understand that > significant work is underway to remedy locking problems present in the > current implementation, and look forward to this service being available. The locking issues stem mostly from the VFS layers consuming kernel services, and the inability to handle this well in union mounts or other many-to-one VFS stacks. They don't really apply to one-to-one VFS stacks, except NFS clients, and that's because it must lock locally, and then proxy remotely and then coelesce locally only when the proxy is successful. This is tantamount to an internal union of 2, and is a special case. [ ... (incorrect) assumed approach ... ] > Actually, this is not the technique I am using. I followed the lead of > the quota file system code, storing attributes in backed vnodes, indexed > by inode on a per-fs basis. This implementation method is subject to > debate, but seems to work well as it stands. As with Quotas, I provide > vfs call, extattrctl, which allows an appropriately privileged user > process to pass a vnode reference (via a file path, probably in the same > fs as the attributes, but not necesarily) down to UFS for a source of > backing data. This requires one backing file per attribute per fs. I think this approach is ideally suited for stacking, much more so than the one I assumed, which was the same one used in the ACLs in the comp.sources.unix archives! > Again, similar to the quota implementation supporting different named > quotas, a chain of vnodes is maintained, each with a name identifying > which attribute it corresponds to. When an attribute is retrieved or > submited, the inode number (acceptable to use since we're within the UFS > layer where we know this information does uniquely identify the file) is > mapped to a location in the file where attribute data may be found. How do you deal with inherited ACLs when a subdirectory tree is renamed from one directory to another? Do you traverse them? The problem with direct inheritance is that the on disk structure for maintaining hard links would have to change, if you were to have a functional "get parent inode" interface of some kind. > If layering worked correctly, and supported an adequate mechanism for > mapping ACLs onto objects consistently between layers, I would be willing > to consider reimplementing ACLs as a layer. With the exception of the object alias problem, it does. Are you willing to use the workaround, at least until such time that the FreeBSD VFS code is fixed? I think that it would be greatly beneficial to have a working stacking layer that actually does something useful! > Similarly, I suppose those > would be possible for attributes. But I object to the idea that extended > attributes and ACLs are not specific to UFS: any individual implementation > will be optimized and designed to solve particular needs, in a particular > way, and based on the filestore properties. I forsee that there will have to be common semantic guarantees, across all file systems. For this to work, I think the code has to be the same code. In particular, I can see that installing "priviledged images" would be an ideal candidate for this. Consider the case of programs which run today as root in order to obtain reserved ports. Now consider an ACL that allows an unpriviledged application to obtain reserved ports. How many security holes are caused by suid root programs that are suid merely to obtain reserved ports? This argues stringly for ACLs in the base system, but they must be ACLs that apply to all VFS types, equally. Especially ext2fs mounted under FreeBSD to obtain a /compat/linux. > In Solaris, > different choices were made: they choose to use "shadow inodes" and allow > ACLs of (effectively) unlimited length. This is the approach I used in NWFS; Sun had access and license to use that source code, actually. I don't know if they did or didn't, or if you are really describing VXFS. > In > NTFS, a generic named file fork service is provided, where the forks are > complete address spaces with the full flat-file semantic. This could be > viewed as an extended attribute, although as I describe in my document my > feeling is this is not appropriate to do :-). This is a namespace fold, of exactly the type I described above. There are at least two other ways to fold a namespace. The useful part of this is that you can use the POSIX namespace escape to directly access these files. This would mean that you would not need to add additional system calls or VOPs, so long as your user space tools did the right thing (a two stage commit using copy+add and two renames to modify/add/delete ACLs). This is a good thing. It's also deterministically recoverable, with roll-forward capability, following a crash in the middle. The primary problem with this approach is that the FreeBSD namei() uses mutual recursion instead oftrue recustrion for component name resoloution, in order to avoid allocating additional namei bufs for symbolic link resoloution. As a result, it's not really possible to inherit the POSIX namespace escape downward more than one level; you either have to prefix each component, or you have to do everything up top. This is actually trivial to fix, however, even if no one has been willing to commit a fix so far. This would allow you to access the files normally: ./foo/fee foo/fee /foo/fee and then directly access the ACLs for those files: //ACL/./foo/fee //ACL/foo/fee //ACL//foo/fee Using POSIX namespace escapes. > My personal feeling on the file fork issue is that we already have a > mechanism to provide multiple complete address spaces under a path, each > with a different name. We even allow this to be done recursively. It's > called a directory tree, and the address spaces are known as files. :-) There is value in folding. Administratively, it lets you apply a policy control to access by removing the semantically controlled address spaces from the user visible name space. Admittedly, you can work around this, but it's rather butt-ugly compared to a fold. 8-). > As such, I disagree with the assertion that it is inappropriate to add new > services to existing file stores: to fail to do so would be to fail to pay > attention to changing requirements. While layering is a useful > extensibility mechanism, it has failed to deliver, and may continue to > fail to deliver. I think that this is not so true; layering has failed to deliver in BSD, but recently, this has been addressed, if not totally satisfactorily, at least functionally. > By keeping ACL and Extended Attribute data within a > single file system, we allow that file system to provide consistency > guarantees not provided in the extisting layering model. You can imagine > transactional and logging file systems maintaining versioning information > on the attributes themselves, as in fact I believe XFS can do. While you > could theoretically extend layering interfaces to provided nested > transactional semantics, theres the important question of whether this is > really feasible, and given the added complexity, entirely desirable. It's feasible, even without explicit transaction semantics. I think that it's inarguably desirable, since so many of us FS geeks desire it. 8-). > Given a sufficently powerful layering mechanism, many things are possible. > If there were any easier way to provide ACL, MAC, and Capability support > under UFS, the chances are I would have done it, but I didn't seem to find > one. I'm sure that, given this forum, the author of the glue code that works around the stacking problem in FreeBSD will step forward; if not, ping me, and I can grovel through my mail and forward his posting to you. > Whether or not the UFS extended attribute code ends up being committed is > a decision I don't think anyone is ready to make yet, given that I'm > probably the only person who has seen them. :-) Either way, the services > are required in a number of environments in the immediate future. In the > short and long term, having both the interfaces defined for these services > will facilitate a lot of further development, including improved support > for HPFS, and the ability to introduce features associated with the > trusted extensions operating system extensions in POSIX.1e. I think that it's also inarguable that EA/ACL facilities _must_ be provided in the near term future; my only objection was in tying them to a specific VFS. I fully support commiting a layer that can do the work. In any case, I did not intend to denigrate your good work, only to ensure that it can be applied universally instead of in a tiny corner, and that it didn't preclude future research along other lines (as it might have, had it permanently stolen the spare fields like the nanosecond timestamp change did). Keep up the good work! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 17 11: 2:39 1999 Delivered-To: freebsd-fs@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 61FDD1576E for ; Fri, 17 Dec 1999 11:02:24 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 25B3F1C03; Sat, 18 Dec 1999 03:02:22 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: robert+freebsd@cyrus.watson.org, freebsd-fs@FreeBSD.ORG Subject: Re: Request for objections: extended attribute and ACL interfaces In-Reply-To: Message from Terry Lambert of "Fri, 17 Dec 1999 02:04:17 GMT." <199912170204.TAA08405@usr07.primenet.com> Date: Sat, 18 Dec 1999 03:02:22 +0800 From: Peter Wemm Message-Id: <19991217190222.25B3F1C03@overcee.netplex.com.au> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: > > Terry, > > > > First let me start by saying that I greatly appreciate your taking the > > time to send your comments--I value your feedback. Please see my comments > > below. > > > > > I personally have no objection to these interfaces. They seem to > > > cover the problem space that you say that they cover, and they are > > > at worst, harmless. > > > > The only functionality I'm not sure how to handle is identifying the > > attributes available on the file for the presence of duplication--where > > they back another file system visible object (such as ACLs, MAC labels, > > etc) then those interfaces should be used to back up the attributes. It > > isn't clear to me that attributes should be backed up independent of > > semantics available to interpret them, as they will most often be used for > > file system services where restoring them and associating them with the > > same file may not make sense, nor even be possible given the rights and > > functionality associated with what they back. I am comfortable not > > defining that behavior just now, and waiting to see what applications > > require it. I can also conceive of write-only attributes, etc. > > The reason I said "harmless" is rather deeper. > > The Heidemann framework supports the ability to add VOP's to an > existing system. FreeBSD doesn't currently support this, but it > could be fixed to do so, simply by making *vfs_op_descs[] a > pointer reference, and reallocating it as needed in order to > grow the descriptor list using loaded descriptors. Terry, why don't you freaking well *look* at the code every now and then? This *is* implemented and works already, for over a year now. kern/vfs_init.c: ---------------------------- revision 1.39 date: 1998/11/10 09:04:09; author: peter; state: Exp; lines: +223 -125 Make the vnode opv vector construction fully dynamic. Previously we leaked memory on each unload and were limited to items referenced in the kernel copy of vnode_if.c. Now a kernel module is free to create it's own VOP_FOO() routines and the rest of the system will happily deal with it, including passthrough layers like union/umap/etc. Have VFS_SET() call a common vfs_modevent() handler rather than inline duplicating the common code all over the place. Have VNODEOP_SET() have the vnodeops removed at unload time (assuming a module) so that the vop_t ** vector is reclaimed. Slightly adjust the vop_t ** vectors so that calling slot 0 is a panic rather than a page fault. This could happen if VOP_something() was called without *any* handlers being present anywhere (including in vfs_default.c). slot 1 becomes the default vector for the vnodeop table. TODO: reclaim zones on unload (eg: nfs code) ---------------------------- Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 17 19: 2:31 1999 Delivered-To: freebsd-fs@freebsd.org Received: from students.itb.ac.id (students.ITB.ac.id [167.205.22.114]) by hub.freebsd.org (Postfix) with SMTP id BF87A14DF7 for ; Fri, 17 Dec 1999 19:02:28 -0800 (PST) (envelope-from otok@students.itb.ac.id) Received: (qmail 38450 invoked by uid 1184); 18 Dec 1999 03:02:24 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Dec 1999 03:02:24 -0000 Date: Sat, 18 Dec 1999 10:02:24 +0700 (JAVT) From: Otok Berliawan To: freebsd-fs@FreeBSD.ORG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Dec 18 3:48:35 1999 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5559314C22 for ; Sat, 18 Dec 1999 03:48:32 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id WAA26491; Sat, 18 Dec 1999 22:48:20 +1100 Date: Sat, 18 Dec 1999 22:48:02 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Pekka Savola Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Deleting a directory on ext2fs crashed the system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 11 Dec 1999, Pekka Savola wrote: > Btw, are there any good ext2 fsck tools? I'm using the ones from Linux > with emulation, but there are some unimplemented system calls or such. The current (?) version of the standard ext2fs tools (e2fsprogs-1.17.tar.gz) builds after a 1-line change and worked almost perfectly in -current until block devices were removed last month. mke2fs must be invoked with "-O none" because the default is set unsafely to "-O filetype,sparse" and FreeBSD's ext2fs doesn't understand ext2fs extensions at all (it panics in readdir() for filesystems created with the "filetype" extension). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Dec 18 12: 5:47 1999 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 653E214D81 for ; Sat, 18 Dec 1999 12:05:44 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA00718; Sat, 18 Dec 1999 13:04:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAA2uaWqb; Sat Dec 18 13:04:42 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA01764; Sat, 18 Dec 1999 13:05:04 -0700 (MST) From: Terry Lambert Message-Id: <199912182005.NAA01764@usr08.primenet.com> Subject: Re: Request for objections: extended attribute and ACL interfaces To: peter@netplex.com.au (Peter Wemm) Date: Sat, 18 Dec 1999 20:05:04 +0000 (GMT) Cc: tlambert@primenet.com, robert+freebsd@cyrus.watson.org, freebsd-fs@FreeBSD.ORG In-Reply-To: <19991217190222.25B3F1C03@overcee.netplex.com.au> from "Peter Wemm" at Dec 18, 99 03:02:22 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Terry, why don't you freaking well *look* at the code every now and then? > This *is* implemented and works already, for over a year now. > > kern/vfs_init.c: > ---------------------------- > revision 1.39 > date: 1998/11/10 09:04:09; author: peter; state: Exp; lines: +223 -125 > Make the vnode opv vector construction fully dynamic. Previously we > leaked memory on each unload and were limited to items referenced in > the kernel copy of vnode_if.c. Now a kernel module is free to create > it's own VOP_FOO() routines and the rest of the system will happily > deal with it, including passthrough layers like union/umap/etc. > > Have VFS_SET() call a common vfs_modevent() handler rather than > inline duplicating the common code all over the place. > > Have VNODEOP_SET() have the vnodeops removed at unload time (assuming a > module) so that the vop_t ** vector is reclaimed. > > Slightly adjust the vop_t ** vectors so that calling slot 0 is a panic > rather than a page fault. This could happen if VOP_something() was called > without *any* handlers being present anywhere (including in vfs_default.c). > slot 1 becomes the default vector for the vnodeop table. > > TODO: reclaim zones on unload (eg: nfs code) > ---------------------------- Peter, it should work without any handlers being present. At the FreeBSDCon, Kirk agreed that the vfs_default.c stuff damaged the abstraction between UFS and FFS layers, which are supposed to be seperated as block management policy and directory hierarchy policy layers. Ask Matt Dillon or Poul-Henning. Peter, there is no rendevous by name for new VOPs so that they can be passed from a loaded stacking layer that knows about a new VOP to an underlying stacking layer that knows about the new VOP, through one that doesn't. For example, an ACLFS layer mounted over top of a translucent FS mounted over top of a read only FS and backing media so that I can put ACLs on the contents of my CDROM that I'm making available to user on my system. If the backing media already knows about VOP_ACL, you are screwed: it's not the same VOP_ACL, unless you imply a dependency between kernel modules that you should not be implying. Peter, the decriptor list isn't sorted so that a dereference can be done by index. Not only is the overhead for this higher, the addition of a new VOP is an O(3) random traversal instead of O(1) linear traversal for existing instanced VFSs. This change is incomplete; it does not fully solve the problem noted in my previous email. Don't assume the code is right and I am wrong, just because you are emotionally invested in the code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Dec 18 13:50:29 1999 Delivered-To: freebsd-fs@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 9037114A2E for ; Sat, 18 Dec 1999 13:50:19 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 32B321CA0; Sun, 19 Dec 1999 05:50:16 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: robert+freebsd@cyrus.watson.org, freebsd-fs@FreeBSD.ORG Subject: Re: Request for objections: extended attribute and ACL interfaces In-Reply-To: Message from Terry Lambert of "Sat, 18 Dec 1999 20:05:04 GMT." <199912182005.NAA01764@usr08.primenet.com> Date: Sun, 19 Dec 1999 05:50:16 +0800 From: Peter Wemm Message-Id: <19991218215016.32B321CA0@overcee.netplex.com.au> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: > > Terry, why don't you freaking well *look* at the code every now and then? > > This *is* implemented and works already, for over a year now. I note that you carefully deleted your original statements, which I'll re-quote for context: > The Heidemann framework supports the ability to add VOP's to an > existing system. FreeBSD doesn't currently support this, but it > could be fixed to do so, simply by making *vfs_op_descs[] a > pointer reference, and reallocating it as needed in order to > grow the descriptor list using loaded descriptors. Fact: you said "FreeBSD doesn't support this", which is wrong. We do add VOP's to an existing system. Fact: your suggestion about making *vfs_op_descs[] a pointer reference is already done, exactly as you suggested, and it was done over 12 months ago. My point that you should *read* the code rather than make blanket statements still stands. Now that you appear to have read it (at last, thank you!), your comments on the implementation are worth something. > Peter, it should work without any handlers being present. And what should it do? OK, suppose there is an expanded VOP_* inline compiled into a binary to do the VCALL() etc. Now, there is no handler or descriptor present. How is the stacking layer supposed to deal with that? It doesn't have an offset to work with.. > At the > FreeBSDCon, Kirk agreed that the vfs_default.c stuff damaged the > abstraction between UFS and FFS layers, which are supposed to be > seperated as block management policy and directory hierarchy policy > layers. Ask Matt Dillon or Poul-Henning. I'm not talking about UFS/FFS layers. I was responding to and talking about one specific part, adding VOPs dynamically. Have you looked at the vfs_default.c stuff BTW? It doesn't do anything unless the target filesystem specifically activates it. If the target filesystem supports some sort of passthrough (such as unionfs), then it doesn't use vop_defaultop() as a catch-all. Unionfs (for example) provides it's own and has absolutely no interference from vfs_default.c. The VOP layer doesn't use vop_default.c unless the terminal filesystem *specifically* requests it when it has no passthrough capabilities. You will note that ffs/ffs_vnops.c (the upper layer) has it's own vop_default handler (ufs_vnopoerate) with passes all unknown VOP's to the lower UFS layer. If UFS can't handle them, then UFS hands it off to vop_defaultop(). FFS is functioning as a passthrough layer. ufs_vnops.c (bottom layer): int ufs_vnoperate(ap) struct vop_generic_args /* { struct vnodeop_desc *a_desc; } */ *ap; { return (VOCALL(ufs_vnodeop_p, ap->a_desc->vdesc_offset, ap)); } ffs_vnops.c (top layer): vop_t **ffs_vnodeop_p; static struct vnodeopv_entry_desc ffs_vnodeop_entries[] = { { &vop_default_desc, (vop_t *) ufs_vnoperate }, <<<< { &vop_fsync_desc, (vop_t *) ffs_fsync }, { &vop_getpages_desc, (vop_t *) ffs_getpages }, { &vop_putpages_desc, (vop_t *) ffs_putpages }, { &vop_read_desc, (vop_t *) ffs_read }, { &vop_balloc_desc, (vop_t *) ffs_balloc }, { &vop_reallocblks_desc, (vop_t *) ffs_reallocblks }, { &vop_write_desc, (vop_t *) ffs_write }, { NULL, NULL } }; ie: ffs specifically intercepts the functions it's interested and then passes the rest through to UFS, *without interference from vfs_default.c*! As UFS is a terminal layer, it (rightly) terminates any unhandled requests. > Peter, there is no rendevous by name for new VOPs so that they can be > passed from a loaded stacking layer that knows about a new VOP to > an underlying stacking layer that knows about the new VOP, through > one that doesn't. For example, an ACLFS layer mounted over top of > a translucent FS mounted over top of a read only FS and backing media > so that I can put ACLs on the contents of my CDROM that I'm making > available to user on my system. If the backing media already knows > about VOP_ACL, you are screwed: it's not the same VOP_ACL, unless > you imply a dependency between kernel modules that you should not be > implying. The descriptors are global scope.. You can't have two different VOP's by the same name. vnode_if.h: extern struct vnodeop_desc vop_islocked_desc; static __inline int VOP_ISLOCKED(vp, p) struct vnode *vp; struct proc *p; { struct vop_islocked_args a; int rc; a.a_desc = VDESC(vop_islocked); a.a_vp = vp; a.a_p = p; rc = VCALL(vp, VOFFSET(vop_islocked), &a); return (rc); } (vnode_if.c contains the declarations of the _desc structs.) VDESC() expands so that it's the equivalent of: a.a_desc = &vop_islocked_desc; This cannot work with two global vop_acl_desc's. We can add and remove descriptors on the fly. An intermediate layer operating in passthrough mode (eg: FFS, unionfs) does not need *any* knowledge of the VOPs being passed through it. You state: > there is no rendevous by name for new VOPs so that they can be > passed from a loaded stacking layer that knows about a new VOP to > an underlying stacking layer that knows about the new VOP, through > one that doesn't. This is not entirely correct. There is no "string" as such, but the rendesvous is a global variable. (eg: vop_acl_desc). It *can* pass through an intermediate layer without interference from vfs_default.c. > Peter, the decriptor list isn't sorted so that a dereference > can be done by index. Not only is the overhead for this higher, the > addition of a new VOP is an O(3) random traversal instead of O(1) > linear traversal for existing instanced VFSs. So? A once-off cost at boot/load/unload time doesn't mean much as long as there isn't a runtime penalty. I don't believe there is a runtime penalty as it uses the exact same VCALL/VOCALL implementation as before. The cost of indexing a 30-odd entry array at boot is nothing compared to things like waiting for IDE disks to stabilize. If you think you can make it faster, be my guest. If you send a single purpose patch that makes it faster without mixing other changes in, you will have my full attention. > This change is incomplete; it does not fully solve the problem > noted in my previous email. I am not denying that more work can be done, but object to you saying that "it isn't supported". The more code I read and check the more I think the problems you talked about aren't real either - aside from not supporting two different VOP_ACL()'s in the same kernel at the same time (which I think is of questionable value - that opens real cans of worms that we could do without.. like *which* VOP_ACL() is which?). > Don't assume the code is right and I am wrong, just because you > are emotionally invested in the code. I am "emotionally invested" in people spreading misinformation and blanket statements that are clearly false. Your claim that FreeBSD does not currently support dynamically adding VOP's is wrong. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Dec 19 0:57:15 1999 Delivered-To: freebsd-fs@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 0C584151EF for ; Sun, 19 Dec 1999 00:57:13 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id JAA05385; Sun, 19 Dec 1999 09:56:30 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: peter@netplex.com.au (Peter Wemm), robert+freebsd@cyrus.watson.org, freebsd-fs@FreeBSD.ORG Subject: Re: Request for objections: extended attribute and ACL interfaces In-reply-to: Your message of "Sat, 18 Dec 1999 20:05:04 GMT." <199912182005.NAA01764@usr08.primenet.com> Date: Sun, 19 Dec 1999 09:56:30 +0100 Message-ID: <5383.945593790@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199912182005.NAA01764@usr08.primenet.com>, Terry Lambert writes: >Peter, it should work without any handlers being present. At the >FreeBSDCon, Kirk agreed that the vfs_default.c stuff damaged the >abstraction between UFS and FFS layers, which are supposed to be >seperated as block management policy and directory hierarchy policy >layers. Ask Matt Dillon or Poul-Henning. Terry, the interface between UFS and FFS isn't a vnode interface, it is an *I*node interface. It shouldn't use VOPs at all. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Dec 21 10:29:14 1999 Delivered-To: freebsd-fs@freebsd.org Received: from emumail.com (chica.emumail.com [208.36.205.162]) by hub.freebsd.org (Postfix) with ESMTP id 25F2915092 for ; Tue, 21 Dec 1999 10:29:11 -0800 (PST) (envelope-from ricardo@emumail.com) Received: from localhost (ricardo@localhost) by emumail.com (8.8.7/8.8.7) with ESMTP id NAA06349 for ; Tue, 21 Dec 1999 13:27:19 -0500 Date: Tue, 21 Dec 1999 13:27:19 -0500 (EST) From: Ricardo Kleemann To: freebsd-fs@freebsd.org Subject: any availability of journalling fs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi everyone, Can anyone tell me if a journal fs exists for freebsd? Thanks Ricardo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message