X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-CMAE-Analysis: v=2.4 cv=LqtUiFRc c=1 sm=1 tr=0 ts=64248e00 a=+cj0cO56Fp8x7EdhTra87A==:117 a=ugyPIEMg1CtdJMf+ey4XCQ==:17 a=9+rZDBEiDlHhcck0kWbJtElFXBc=:19 a=gQX1269ULFhLm4Thdby34LUHVW0=:19 a=IkcTkHD0fZMA:10 a=k__wU0fu6RkA:10 a=ZLGELXoPAAAA:8 a=Mj1Xp5F7AAAA:8 a=VWECln9F5O-ZmhimVrwA:9 a=QEXdDO2ut3YA:10 a=gFE-7FYHWvNzGF8b5qNZ:22 a=CFiPc5v16LZhaT-MVE1c:22 a=OCttjWrK5_uSHO_3Hkg-:22 X-SECURESERVER-ACCT: glimrick AT epilitimus DOT com Subject: Re: [geda-user] Changing gschem backup file permissions To: geda-user AT delorie DOT com References: <4772851a-fca0-4370-d6bb-ef854127e604 AT fastmail DOT com> <220e2113-ca15-9f9b-107b-b9609d3cc2ef AT fastmail DOT com> From: "Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" Message-ID: <42e62e95-75b0-233e-ce87-f4e4dce869fd@epilitimus.com> Date: Wed, 29 Mar 2023 11:14:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.3 MIME-Version: 1.0 In-Reply-To: <220e2113-ca15-9f9b-107b-b9609d3cc2ef@fastmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2plcpnl0121.prod.iad2.secureserver.net X-AntiAbuse: Original Domain - delorie.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - epilitimus.com X-Get-Message-Sender-Via: a2plcpnl0121.prod.iad2.secureserver.net: authenticated_id: glimrick AT epilitimus DOT com X-Authenticated-Sender: a2plcpnl0121.prod.iad2.secureserver.net: glimrick AT epilitimus DOT com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4xfKc5/SlXDjiB1DM47t8EqlC1pmkf+woMdpKbPxKfUgYUREiHfesxAjX4yfcfB9ssCjwhh/iS0xB+/zkEU/o2TMq9K7me+p8WMTiVDuYDQoZti31roFRG qPl3LgSJ3pPojAN2GV2UIUX9B3jkKQ3QSEfTqTs7aKqp87uqPJTg9Tq7i93oVOVhGoeyhaP8WK89IUr2RtX9VX/m6Hua+q38JMvgM4MP3Ssp+SDRvwRACurG Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Girvin, Not sure but you might find rsync useful, it is intended for doing archival/backup/mirroring work. As I recall it preserves file permissions. Some files may be read only for a,security reason. Glenn Girvin Herr (gherrl2 AT fastmail DOT com) [via geda-user AT delorie DOT com] wrote: > > On 3/27/23 6:13 PM, Roland Lutz wrote: >> On Mon, 27 Mar 2023, Girvin Herr (gherrl2 AT fastmail DOT com) [via >> geda-user AT delorie DOT com] wrote: >>> That is what I was afraid of. I was hoping it could be done in a >>> configuration file somewhere. Thanks for the info, though. >> >> Well ... if you don't want do re-build gEDA/gaf from source, you >> could always binary-patch the library. >> >> Go to the directory (e.g., /usr/local) where you installed gEDA/gaf. >> Make a backup copy of your libgeda library: >> >> $ cp -i lib/libgeda.so.47.0.0 lib/libgeda.so.47.0.0.backup >> >> Look at the disassembled library to find the relevant code location: >> >> $ objdump -d lib/libgeda.so.47.0.0 | less >> >> You can use "/f_save" to search for the function name and "n" to >> skip over the procedure linkage table entry (we are not interested in >> that) until you get to the actual function.  This should look >> something like this: >> >> 0000000000023a20 : >>    23a20:       41 57                   push   %r15 >>    23a22:       41 56                   push   %r14 >>    23a24:       41 55                   push   %r13 >> (and so on) >> >> Now, look for the AND instruction ("/and") that clears the write >> bits in the permissions (ug-wx o-x = 0446 = 0x126). There are two AND >> instructions in f_save; in my case, the relevant one is the second >> one. It should look something like this: >> >>    23e44:       31 ff                   xor    %edi,%edi >>    23e46:       e8 15 1a ff ff          callq  15860 >>    23e4b:       48 8b 7c 24 10          mov    0x10(%rsp),%rdi >>    23e50:       89 c6                   mov    %eax,%esi >>    23e52:       89 44 24 1c             mov    %eax,0x1c(%rsp) >>    23e56:       f7 d6                   not    %esi >>    23e58:       81 e6 26 01 00 00       and    $0x126,%esi >>    23e5e:       e8 1d f2 fe ff          callq  13080 >> >> The previous umask is stored in %esi, inverted, masked with 0x126, >> and passed to chmod.  We want to change the permission mask, so it is >> the address of the AND instruction we are interested in (0x23e58 in >> my case, but yours will be different), as well as the exact machine >> text (81 e6 26 01 00 00 in my case). >> >> Copy that information, close the disassembly ("q") and run Python.  >> Open the shared library, seek to the position you determined and see >> if you get the bytes you saw in the disassembly (make sure to enter >> the extra newline after the third line of code to tell Python the >> block is over): >> >> $ python3 >>>>> with open('lib/libgeda.so.47.0.0', 'rb') as f: >> ...     f.seek(0x23e58)  # <-- replace with your value >> ...     f.read(6) >> ... 147032 >> b'\x81\xe6&\x01\x00\x00' >> >> Looks good!  The ampersand is ASCII 0x26, so it's displayed as a >> visual character, but it is the correct value.  Now replace the mask >> with the one we want (ugo-x = 0666 = 0x1b6), otherwise using the >> exact same bytes as seen in your disassembly: >> >>>>> with open('lib/libgeda.so.47.0.0', 'r+b') as f: >> ...     f.seek(0x23e58)  # <-- replace with your value >> ...     f.write(b'\x81\xe6\xb6\x01\x00\x00')  # <-- this too >> ... 147032 >> 6 >>>>> ^D >> >> (For Python 2, you need to omit the "b" before the byte string.) >> >> You're done!  Now verify that you did indeed change the correct >> instruction.  You should see exactly one changed byte (from 26 to b6): >> >> $ diff <(objdump -d lib/libgeda.so.47.0.0.backup) <(objdump -d >> lib/libgeda.so.47.0.0) >> 2c2 >> < lib/libgeda.so.47.0.0.backup:     file format elf64-x86-64 >> --- >>> lib/libgeda.so.47.0.0:     file format elf64-x86-64 >> 19164c19164 >> <    23e58:     81 e6 26 01 00 00       and    $0x126,%esi >> --- >>>    23e58:     81 e6 b6 01 00 00 and    $0x1b6,%esi >> >> If this is what you see, the binary patch has succeeded, and you >> should have the file permissions you want the next time you run >> gschem.  If you see changes different than that (or no changes at >> all), DELETE the botched library and restore it from the backup. >> >> Hope that helps! >> >> Roland >> > Roland, > > Thanks for the info. I may take a look at it, but I prefer to use the > unchanged package from gEDA. > > I have been giving my problem some thought and I think it will be > better to create a script to change all 4xx file permissions to 6xx. > That should catch all of the files that are giving me problems, > including any non-gschem files, or even files located in a directory > other than the one I invoke gschem from. It sounds better to me. > > Thanks again. > > Girvin > > >