bug-gv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gv] error opening files on other directories


From: jemarch
Subject: Re: [Bug-gv] error opening files on other directories
Date: Mon, 15 Nov 2004 14:20:03 +0100

        > It is possible to tell gs to accept non-trivial paths while remaining
        > "safe"? Is the safe/unsafe state monolithic?
        
        I think safer is monolithic. From the manual:
        
        -dSAFER: Disables the deletefile and renamefile operators, and the 
ability to
        open piped commands (%pipe%cmd) at all. Only %stdout and %stderr can be 
opened
        for writing.  Disables reading of files other than %stdin, those given 
as a
        command line argument, or those contained on one of the paths given by 
LIBPATH
        and FONTPATH and specified by the system params /FontResourceDir and
        /GenericResourceDir.
        
        jemarch wrote on 
https://savannah.gnu.org/bugs/?func=detailitem&item_id=10992:
        > I would suggest to translate this discussion (and other bug related
        > discussions) to address@hidden I think bug tracker follow-up comments 
should
        > be used only in case of a change of the bug state.  Do you all agree?
        
        I have seen the bug tracker follow-up been used for discussion on 
several
        projects, but I don't mind using the mailing list - here I go:
    
    Thanks.
        
        Just some more comments:
        > gs -dSAFER ../test/grfguide.pdf
        is OK.
        > ./gv ../test/grfguide.pdf
        isn't OK, while
        > ./gv ../test/grfguide.ps
        is OK. (Assuming "safer" is set in gv of course.) Is there any 
difference in
        how we treat pdf vs. ps files?
    
    No difference. If the file is pdf, then gv launch a gv interpreter to
    run `pdf2dsc.ps' in order to generate the dsc file.
    
    The dsc add some stub postscript code and include the pdf. So if we
    trust pdf2dsc.ps (why dont do that?) then it is safe to not include
    -DSAFER on pdf2dsc.ps execution. This assumes that the pdf is also
    safe, which will always be due to the static nature of the PDF
    format. 
    
    Please note the gs interpreter used to build the dsc (that do not work
    on SAFER mode) is _not the same_ that the actual gs interpreter used
    to interpret the actual ps page.
        
    
    So i think we simply can remove the -DSAFER from the invocation for
    scanning the pdf file.

Wrong. -DSAFER is not called for the dsc generation.

Anyway the SAFER violation must be in code like this (this is a dsc file):


%!PS-Adobe-3.0
%%CreationDate: (D:20041115132700)
%%DocumentMedia: y841.89x595.276 595.276 841.89 70 white ()
%%Pages: 1
%%EndComments
%%BeginProlog
/Page null def
/Page# 0 def
/PDFSave null def
/DSCPageCount 0 def
/DoPDFPage {dup /Page# exch store pdfgetpage pdfshowpage } def
GS_PDF_ProcSet begin
pdfdict begin
%%EndProlog
%%BeginSetup
(small2e.pdf) (r) file { DELAYSAFER { .setsafe } if } stopped pop
 pdfopen begin
%%EndSetup
%%Page: 1 1
%%PageMedia: y841.89x595.276
1 DoPDFPage
%%Trailer
currentdict pdfclose
end
end
end
%%EOF


So it is actually a pdf2dsc.ps bug... since its outpus is no more
executable in safe mode by GPL gs 8.15






reply via email to

[Prev in Thread] Current Thread [Next in Thread]