On Apr 9, 2011, at 6:49 PM, Tomasz Pala wrote: > On Sat, Apr 09, 2011 at 17:09:54 -0400, Jeff Johnson wrote: > >> And I'm not disagreeing. How rpm should handle xattr's like >> that capabilities you want is a whole different matter. >> >> Attaching Yet Another per-file tag everywhere just to set >> a capaibility for, say, ping and perhaps 100-300 other >> files (there's often > 1M, try "rpm -qal | wc -l") >> is a fairly expensive undertaking. >> >> And its quite silly to have _EVERY_ file have an attached (and >> usually empty/missing) capability when the right approach >> is to run a short list of paths that *do* need a capability attached. > > Still, this is an implementation detail I won't meddle. The other time > you've mentioned that this could be accomplished by %post(un) and > %verify, so as far as I'm concerned %files section could have %acl or > %caps tags which would be converted to appropriate functions during spec > parse or something, you might be right that it doesn't make much sense to > attach them to every single file. > >> (the above is wrto what is implemented @rpm.org) > [...] >>> I can't - rpm doesn't support xattrs (or it's so top secret you can't >>> tell me how to do this). >> >> Bullshit: rpm.org supports capabilities, > > And %caps() only - without ACLs, we could have use for, e.g. > default:group:logs:r on /var/log as currently some logs are NOT readable > by user in logs group and this is beyond caps scope (DAC_OVERRIDE would > be per entire user x app set). > >> I personally can't justify adding Yet Another per-file tag, but >> if that's what you want, I can/will add *exactly* what is at >> rpm.org under a vendor-peculier #ifdef. > > What exactly is the overhead of empty tag?
FOr a distro containing >1M files, empty string tags require (at least) '\0'.
But ~1Mb (for a 1M file distro) additional info is moderately significant. Go
look at
ls -al /var/lib/rpm/Packages
run
rpm -qal | wc -l
and then add that number of bytes for an empty tag. Then also
add that to download times, and space on RO media.
Already all strings are saved in rpmdb indices without trailing '\0'
in order to save several megabytes of space.
>
>> What do you think about radiation leakage in JA? Does that concern you or
>> not?
>
> It doesn't.
>
>> I kinda prefer Hillary over Obama: chicks in charge! Are there any females in
>> positions of power in Poland? I just heard about MAM in France, she's cool!
>
> Sorry, don't care either.
>
>> I've tried repeatedly to avoid argument:
>> Patches cheerfully accepted.
>> if you want to remove SUID's and use capabilities instead.
>
> There are patches - in rpm.org as you know.
>
I'm well aware of what is @rpm.org even if you are not. You claimed
that rpm was preventing you from remoing SUID.
I'm also aware that Fedora tried removing SUID, and has packaged
with capabilities. *shrug*
There's lots of ways to run a command against 100-300 files to
add capabilities "securely", without raciness, and without
getting "package management" involved. SInce you are adding a capabity,
it just means that the file will be installed in unprivlieged
capabilty-free mode until the capability is added, just like SUID's.
And ultimately, neither @rpm5.org or @rpm.org code is in use by PLD,
so it matters about as muct as radiation damage and chicks in charge
discussions.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
