python3.2+ compiled files

[Jeff Johnson]

On Apr 9, 2011, at 4:16 PM, Tomasz Pala wrote:

> 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.
> 

You WILL have users using python eggs, and there WILL be a window
installing content outside of package management.

Similarly true for CPAN and ruby gems and whatever PHP
and JavaScript are doing.

The approach in SELinux is inheirited xattr's from well known directories.

None of the above involves rpm "package management" installing xattr's.

And none of the above precludes rpm from attaching xattr's where it makes sense.
This thread started -- not about secuirity -- but how to handle
*.pyo side effects.

>> 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).
> 

SO get rid of SUID. What SUID has to do with "package management" of
*.pyo side-effects isn't clear.

>>> 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)?
> 

How does rpm store data in an rpmdb? You look at the schema,
you create records conistent with the schema, and you write
tools to make that happen for other data.

Reasoning from "RPM has a database" -> "All content MUST be delivered
in *.rpm packages" -> "I want to remove SUID's!" is rather muddled.

>>> 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).
> 

And this thread started (see Subject:) with

	What should be done with python's Newer! Better! Bestest!
	convention for storing compiled *.pyo files?

not anything else.

And all I wished to point out is the (rather flawed imho) reasoning
that led to putting *.pyo files into *.rpm packages so that
SELinux trolls could pretend to a solution based on security tags
instantiated in xattr's.

73 de Jeff

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/5ac75fc7/attachment.p7s>