On Tue, Jan 14, 2003 at 12:39:08PM +0100, Michael Schloh von Bennewitz wrote:
>On Tue, Jan 14, 2003, Ralf S. Engelschall wrote:
>> On Mon, Jan 13, 2003, Bill Campbell wrote:
>>> I understand that. My suggestion pertained more to the documentation than
>>> the implementation on the grounds that the names are familiar to Unix
>>> admins and developers.
>>
>> Yes, you're right, the documentation for these issues is still very
>> bad. There is just a small and confusing paragraph about this in the
>> handbook.
>>
>Now there's a big and confusing paragraph in the handbook ;-)
I think the reason this is confusing is that in the present implementation
none of this seems to be implemented. Everything in an openpkg instance is
owned by the manager user and in the manager group.
If the %{l_prefix}/RPM/{PKG,SRC,TMP} build directories were in the
restricted user and group (e.g. developers), perhaps with group write
permissions, then developers would work there. This would require the
manager to install software in the instance, and would prevent developers
from changing installed things in the openpkg instance. It would be left
to the developers to set appropriate permissions in the data areas of their
packages so that their target users could access and write as necessary for
their applications.
This then leaves the ``nobody'' user/group which can be used to control
access to the individual applications in an instance at a fairly high level
(e.g. user is accounting manager, group is people who have working access
to accounting data, but can't change configuration of an accounting
package).
The developer restrictions could then be implemented by changing the %files
in the openpkg.spec file (assuming group read/write and no outside users
accessing the developer area).
%attr(0770,%{l_muser},%{l_rgrp} %dir %{l_prefix}/RPM/SRC
%attr(0770,%{l_muser},%{l_rgrp} %dir %{l_prefix}/RPM/PKG
%dir %{l_prefix}/RPM/DB
%attr(0770,%{l_ruser},%{l_rgrp} %dir %{l_prefix}/RPM/TMP
This might require setting ``umask 007'' for the developers.
This would do much the same thing for developers to restrict accidental or
unauthorized changes to packages that openpkg does to restrict changes to
the system's critical files. It shouldn't change the current behaviour
when the default --user=xxx and --group=xxx is specified, and permits more
control for those who want it. Furthermore, things are less confusing in
the documentation because there are well defined guidelines and procedures
to be documented.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
``The trouble with fighting for human freedom is that one spends most of
one's time defending scoundrels. For it is against scoundrels that
oppressive laws are first aimed, and oppression must be stopped at the
beginning if it is to be stopped at all.'' -- H. L. Mencken
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
