bugs: dev, setup, inne

Jakub Bogusz qboosh w prioris.mini.pw.edu.pl
Czw, 22 Cze 2000, 23:22:58 CEST


On Wed, 21 Jun 2000, Tomasz Kłoczko wrote:
> Wogóle to zapewne czytaliście tekst jaki jest w nagłówku group.conf (?).
> 
> # *** Please note that giving group membership on a session basis is
> # *** NOT inherently secure. If a user can create an executable that
> # *** is setgid a group that they are infrequently given membership
> # *** of, they can basically obtain group membership any time they
> # *** like. Example: games are alowed between the hours of 6pm and 6am
> # *** user joe logs in at 7pm writes a small C-program toplay.c that
> # *** invokes their favorite shell, compiles it and does
> # *** "chgrp games toplay; chmod g+s toplay". They are basically able
> # *** to play games any time... You have been warned. AGM
> 
> Najgorsze w tym wszystkim jest to, że nie ni przychodzi mi jakiekolwiek
> inne rozwiązanie powyższego problemu.

Fakt... tu akurat widać zaletę redhatowego console.perms...
Tyle że tamto działało tylko dla jednego usera naraz, a nawet jedna osoba
może używać więcej kont pracując na konsoli.

> Możemy przyjąć, że świadomie godzimy się na to co jest w nagłówku
> group.conf i szukamy dalej docelowego rozwiązanai powyższego.
> Jednym z pośrednich rozwiazań może IMHO być takie zmodyfikowanie
> pam_grupp, żeby w w trzecim polu możan było podać nie tylko użytkownika
> ale także grupę. Wtedy mozanby np. mieć grupę uzytkowników np. trusted
> czy pam_group wobez to której grupy miałoby się pewność, że możnba im
> zaufać, że nie wykorzystają oni tego co jest zawarte w nagłówku
> group.conf.

Na razie lepszego rozwiązania nie widzę...


Teraz ciąg dalszy tego, co wychodzi przy przebudowywaniu pakietów - tym
razem dotyczy narzędzi do sgml i docbooka:

- budowanie pakietu sgml-tools wywala się na robieniu dokumentacji, jeżeli
w systemie nie ma już zainstalowanego sgml-tools - ponieważ Makedoc.sh
usiłuje wywołać skrypty sgml2* z $PATH, a są zainstalowane dopiero
w ${RPM_BUILD_ROOT}%{_bindir}. Sama modyfikacja $PATH przed wywołaniem
nie pomogła, wywalał się kawałek dalej nie mogąc znaleźć czegoś do perla
(EntityMap.pm?).

- rozumiem, że w PLD mają być opensp, openjade i docbook-sgml*, a nie
jade, sp i docbook*-dtd? Te ostatnie nie budują się bez zmiany speców, bo
nie ma już install-sgml-catalog, poza tym coś nie bardzo chciały działać.

Ale jeżeli opensp, openjade i docbook-sgml*, to:
w docbook2X jest Requires: docbook, natomiast w docbook-sgml* jest
tylko Provides: docbook-dtd - więc zależności nie są spełnione; po
instalacji z --nodeps działał - no, prawie, bo:
w docbook2man jest wywołanie onsgmls <$1 - a to powodowało jakieś dziwne
błędy:

$ docbook2man libggi-api.sgml
onsgmls:<OSFD>0:139:10:E: end tag for element "REFSECT1" which is not open
onsgmls:<OSFD>0:139:20:E: document type does not allow element "REFSECT1" here
onsgmls:<OSFD>0:152:9:E: document type does not allow element "REFSECT1" here
onsgmls:<OSFD>0:159:10:E: end tag for element "REFENTRY" which is not open
onsgmls:<OSFD>0:268:29:E: end tag for element "SECT1" which is not open
docbook2man: Failed to convert manpage

i budowało się tylko 19 z 29 plików man. Co dziwniejsze, w podanych
liniach wcale nie było ww. tagów...

Natomiast po zmianie wywołania na onsgmls $1 działa dobrze.


-- 
Jakub Bogusz
mailto:qboosh w prioris.mini.pw.edu.pl



Więcej informacji o liście dyskusyjnej pld-devel-pl