Re: [Rpm-maint] ACL and File Capability Support in RPM
On Thu, 13 Nov 2008, Andrew G. Morgan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew G. Morgan wrote: So assuming I can't rely on cap_compare() always being there (it being Linux-specific extension and even then only in very recent libcap), would the following be a reasonable fallback: If cap_size() of both sets are equal, grab external presentation of both and memcmp() them? Yes, that would work - if their size is different they don't match ;-) http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=db1f9af5e2a4443e64ce10112a9553204bab7f4e I don't see this implemented yet. Is fixing this still on your radar? Ok, should be fixed now: http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=e0e0a5e0352fcc8aebe5a4752d672399151aee3f Again, thanks for pointing this out (and kicking my lazy butt to actually fix it ;) - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] ACL and File Capability Support in RPM
Panu and all, thanks for implementing this feature! Andreas ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] ACL and File Capability Support in RPM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Panu, The following change looks a little problematic: http://rpm.org/gitweb?p=rpm.git;a=blobdiff;f=lib/verify.c;h=69fcd162a02fbb43ade1b6635e2f651ff43a9e8e;hp=4658ce99367b6820772554ca90887bf2a3ab026e;hb=db1f9af5e2a4443e64ce10112a9553204bab7f4e;hpb=97ab15cc9eadc1aab563b87a0c92d559cd9e9a41 Specifically, cap_size() refers only to the cap_copy_ext() size of the capability set and not the sizeof(*cap_t), so the memory comparison: memcmp(cap, fcap, cap_size(cap) is not reliably comparing the capability sets - at best this comparison is fragile. Cheers Andrew Panu Matilainen wrote: On Mon, 27 Oct 2008, Panu Matilainen wrote: I added the initial bits to rpm.org HEAD yesterday, essentially Andreas' patch except using libcap instead of looking at file xattr info. I intend to implement + add the rest fairly soon. ...and the rest is committed to rpm.org HEAD now. Might be missing some corner cases and odd bits but the basics work: - spec filelist now accepts %caps(capabilities) and stores in headers - install/upgrade set capabilities on filesystem - verification is updated to match with the above - Panu - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJCdm0+bHCR3gb8jsRAj1tAJ9xgGdiE9DsJQGRejejU9qrCFb/rgCdGP1Y TECIvIFcVOPJhb4grLcmwpc= =ql9P -END PGP SIGNATURE- ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] ACL and File Capability Support in RPM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Panu Matilainen wrote: On Thu, 30 Oct 2008, Andrew G. Morgan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Panu, The following change looks a little problematic: http://rpm.org/gitweb?p=rpm.git;a=blobdiff;f=lib/verify.c;h=69fcd162a02fbb43ade1b6635e2f651ff43a9e8e;hp=4658ce99367b6820772554ca90887bf2a3ab026e;hb=db1f9af5e2a4443e64ce10112a9553204bab7f4e;hpb=97ab15cc9eadc1aab563b87a0c92d559cd9e9a41 Specifically, cap_size() refers only to the cap_copy_ext() size of the capability set and not the sizeof(*cap_t), so the memory comparison: memcmp(cap, fcap, cap_size(cap) is not reliably comparing the capability sets - at best this comparison is fragile. Oops... thanks for pointing this out. So assuming I can't rely on cap_compare() always being there (it being Linux-specific extension and even then only in very recent libcap), would the following be a reasonable fallback: If cap_size() of both sets are equal, grab external presentation of both and memcmp() them? Yes, that would work - if their size is different they don't match ;-) Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJCgAG+bHCR3gb8jsRAgmlAKCd1UQ/Xs+9thRfRGp9OohyB0OIxgCg1XzO SHp9mfC5yiI2YptShOg8u7Y= =8FGc -END PGP SIGNATURE- ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] ACL and File Capability Support in RPM
On Thu, 30 Oct 2008, Andrew G. Morgan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Panu, The following change looks a little problematic: http://rpm.org/gitweb?p=rpm.git;a=blobdiff;f=lib/verify.c;h=69fcd162a02fbb43ade1b6635e2f651ff43a9e8e;hp=4658ce99367b6820772554ca90887bf2a3ab026e;hb=db1f9af5e2a4443e64ce10112a9553204bab7f4e;hpb=97ab15cc9eadc1aab563b87a0c92d559cd9e9a41 Specifically, cap_size() refers only to the cap_copy_ext() size of the capability set and not the sizeof(*cap_t), so the memory comparison: memcmp(cap, fcap, cap_size(cap) is not reliably comparing the capability sets - at best this comparison is fragile. Oops... thanks for pointing this out. So assuming I can't rely on cap_compare() always being there (it being Linux-specific extension and even then only in very recent libcap), would the following be a reasonable fallback: If cap_size() of both sets are equal, grab external presentation of both and memcmp() them? - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] ACL and File Capability Support in RPM
On Sat, 25 Oct 2008, Andrew G. Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Panu Matilainen wrote:
I'm ok with adding the functionality they provide, but I think we should
use libcap and libacl instead of looking at the extended attributes
directly. libacl and libcap provide a portable interfaces (POSIX drafts)
to the features whereas extended attributes are basically just an
Linux/filesystem specific implementation detail (AFAIK).
If I was familiar with how rpm tracks files and meta-data, I'd be happy
to supply a libcap using patch for the rpm code. However, I'm not at all
up to speed on the rpm source code.
All rpm file metadata is stored in rpm headers, details vary on the type
of metadata. What's needed for real capability support is coming up with a
way to sanely store capabilities in headers, teaching the spec parser to
grok %caps() or such in spec filelists and storing them into headers. And
finally to have the capabilities applied on installation.
As rpm doesn't support arrays of binary data in headers (except by
encoding to string arrays), the most straightforward way is probably to
store the capabilities to headers in text format instead of cap_copy_ext()
presentation. And as the files with capabilities attached are going to be
relatively few and far between, storing them needs some extra hoops to
avoid unnecessary header bloat for non-existent data.
So a fair amount of stuff needs doing, but none of it particularly hard.
What was easy though was to add a '-v' option to libcap's (2.14) setcap
utility. You can use it to verify that the capabilities on a file are
what you expect them to be:
Set the capability:
$ sudo ./setcap cap_setfcap=i setcap
Verify the capability:
$ ./setcap -v cap_setfcap=i setcap
setcap: OK
$
The source code change was pretty trivial.
http://git.kernel.org/?p=libs/libcap/libcap.git;a=blobdiff;f=progs/setcap.c;h=65a1cb49438d1dd7991bd306b40460fe3d0b35ea;hp=0501a9d95665a3ac388cbc164f6a8ca1011693a7;hb=9da338a75b5ae27e3f4226d214977a921d644e60;hpb=9f2e7c5245fc3100ed08d8a133f80afd88e81632
Basically:
cap_t ref = cap_from_text(text_for_reference_caps);
cap_t actual = cap_get_file(filename);
if (actual == NULL) {
/* assuming you want to treat no file caps as
equivalent to set as empty, this may or may
not be appropriate for a package manager. */
actual = cap_from_text(=);
}
if (cap_compare(actual, ref) == 0) {
// they are the same
} else {
// not same
}
cap_free(ref);
cap_free(actual);
Hope that helps
libcap interface is a breeze really, no problems there :)
I added the initial bits to rpm.org HEAD yesterday, essentially Andreas'
patch except using libcap instead of looking at file xattr info. I intend
to implement + add the rest fairly soon.
- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] ACL and File Capability Support in RPM
On Mon, 1 Sep 2008, Andreas Gruenbacher wrote: Hello all, I am trying to get the minimal bits and pieces into place for allowing us to start using file capabilties. Cool. Currently, rpm neither supports acls nor file capabilities [1], and so when they are needed, the usual way is to set them in the %post script. This works, but unfortunately rpm then cannot --verify that a file has the right permissions and capabilities attached. In am not aware of any cases where acls would actually be needed for packaged files, so I think that we can safely leave acl support out of rpm for now. It would be nice to check for acls in --verify, though. Agreed, implementing full ACL support doesn't seem necessary (at least yet). With file capabilities, things are different: distributions are going to start using them instead of suid root binaries, and perhaps to run some daemons with fewer privileges. The number of packages using capabilities won't be huge, but sure more than a hand full. I believe that full capability support in rpm would be very useful. I am not familiar enough with the rpm codebase, and I don't think I can implement full file capability support efficiently. Capability support would be useful indeed, and adding support for them been on my mind for a while now, even if it's missing from all the 15 different TODO/roadmap/etc docs out there :) Nevertheless, rpm can meanwhile at least make sure in --verify that no files have capabilities attached. To allow turning this check off, a new %verify file list flag and a new --nocaps command line option seems to make sense for me. The attached two patches against (our version of) rpm-4.4.2 do the following: verify-acls.diff In --verify, also check for POSIX ACLs as part of the mode checks, and complain if any are found. verify-file-capabilities.diff Introduce a new caps %verify flag, and allocate a flag for it. Introduce a new --nocaps command line option. In --verify, also check for the presence of file capabilities, and complain if any are found. Use P as the indicator letter in the --verify output (in a new column). What do you think -- do these patches look acceptable? I'm ok with adding the functionality they provide, but I think we should use libcap and libacl instead of looking at the extended attributes directly. libacl and libcap provide a portable interfaces (POSIX drafts) to the features whereas extended attributes are basically just an Linux/filesystem specific implementation detail (AFAIK). - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
