python3.2+ compiled files

Tomasz Pala gotar at
Sat Apr 9 22:16:12 CEST 2011

On Sat, Apr 09, 2011 at 15:56:04 -0400, Jeff Johnson wrote:

>>>>> There's no known reason why xattr's can't be done in other ways.
>>>> Like what?
>>> Like not having RPM attach xattr's.
>> Please tell me how to do root-free (capabilities-based) system without
>> xattrs in rpm - doing this outside upgrade procedure leaves window for
>> making system unusable in cases like power failure.
> You asked for me to explain "other ways".

And I've shown that this "way" is wrong - having xattrs outside package
manager is bad design per se.

> I am not obligated
> nor inclined to argue security packaging with anyone in public.
> I quite well know what *I* would do instead; but the issue here is
> what *you* want to do in PLD.

I want to get rid of SUID. If you know how to do this - please tell. The
only way I'm aware is by storing xattrs in rpm packages either directly
or by some mechanism bound tightly to upgrade procedure (I don't know
rpm internals if that's possible now).

>> Now we're using some dumb solutions like 'admin' group for SUID ICMP ping
>> instead attaching proper file capabilities. In long term we should
>> remove ALL SUID binaries from distribution, as this approach is broken
>> by design and should be obsoleted 10 years ago.
> That is your right and privilege to do whatever you wish to do.

So how can I store these caps in rpm? Or force rpm not to overwrite
these set by me in filesystem (manually or by other tool)?

>> Not sure about PLD but I suppose we just followed what the others were
>> doing. Other distros did it this way so they could set proper selinux
>> attributes.
> basically arguing "Do what everyone else is doing." when the
> reality is actually that SELinux wussed out on proper engineering
> 5+ years ago (and is considerably improved since).

I'm not referring to SELinux, it's overcomplicated for most of the
people. Unlike xattrs, which ARE contemporary replacement of ancient
file permissions (ACL) and authorization management (capabilities).

Tomasz Pala <gotar at>

More information about the pld-devel-en mailing list