SeaMonkey downloads and Unix permissions

[David McKenna]

 Hi everyone,

When downloading files using SeaMonkey 2.42.9esr, the downloaded files are always marked like these are when running 'ls -l':

[D:\junk\dl]ls -l
total 55308
-rw------- 1 root root 28717328 Jan  5 22:26 Bluegriffon_1-1-1r2.zip
-rw------- 1 root root  3688568 Jan  7 15:49 CUSeeMe2_1-9c.zip
-rw------- 1 root root    27946 Jan  8 08:23 ndpsmb-3.7.3-samba411-20220108.zip

 showing they can be read and written by the owner (root) only. Not a big deal in OS/2, because it pays no attention to these permissions anyway. But things get 'interesting' when you copy these files to a SAMBA server, because it DOES pay attention to these, and so from OS/2 if you try to move, copy, rename, open, or execute one of these files on the server, it doesn't work!

 Is there a setting in SeaMonkey that can change this? Or in OS/2? Why is SeaMonkey doing this? Up to now, I just do a 'chmod 777' on the files before copying them to the server, but would really like to not have to do that. Looking for some enlightenment here...

Regards,

[Dariusz Piatkowski]

I'm curious if this would work as a work-around?

If your SAMBA server (and therefore the Samba server account) that you are connecting to has your ID belonging to the admin/root group, would copying the files from OS/2 allow you to create the TARGET file with the Samba ID matching permissions?

In other words: make sure the Samba connection ID you are using has the best-fitting persmissions so that when you create that file on the Samba server the file inherits your Server ID permissions, as opposed to the original permissions the file was created with on our OS/2 platform.

Makes sense I hope?

I haven't tried this, but from the very start of getting my NAS box connection up and running I was always using my 'admin' ID to connect with, and on the NAS box itself I have my personal ID set as part of the 'Admin' group.

[Dave Yeo]

Hi David,
As far as I know, it is a libc thing. Every program that is built with GCC and kLIBC or LIBCN does this. Though interestingly looking at my downloads directory, I see some exceptions,

Code: [Select]

Z:\Mozprofiles\Downloads>ls -l t*
-rw------- 1 root root   337456 Sep 17 13:46 tafeld08.zip
-rw-r--r-- 1 root root  9467730 Mar 31  2021 test.tar.gz
-rw-r--r-- 1 root root        0 Feb 29  2032 test.tim
-rw------- 1 root root   132668 Aug 13 21:40 testlog-3.43.exe
-rw------- 1 root root 28325320 Apr 19  2021 timidity_eawpats_r12.wpi
-rw------- 1 root root  1895960 Apr 19  2021 timidity_player_2132_os2_r3.wpi
-rw------- 1 root root     4470 Oct 12  2020 tmrtest2.zip
-rwxr-xr-x 1 root root    90333 Feb  2  2021 tolower_ld.exe
-rw------- 1 root root     3695 Feb  2  2021 tolower.c
-rw------- 1 root root      696 Feb  2  2021 tolower.mak
-rw------- 1 root root     3695 Feb  2  2021 toupper.c
-rwxr-xr-x 1 root root    90333 Feb  2  2021 toupper.exe
-rw------- 1 root root    31368 May  4  2021 tracerte.zip
-rw------- 1 root root     8941 May  7  2020 tree.zip
-rw------- 1 root root    59111 Jul 17 16:04 TestDosGetDateTimeTzSetAndRuntime_exe-20130612.zip
-rw------- 1 root root    74865 Jul 18 14:14 TestDosGetDateTimeTzSetAndRuntime-20210718.zip
-rwxrwxrwx 1 root root     6228 Feb  2  2021 TOLOWER.EXE

wish I could remember why. I think the toupper.exe/tolower.exe were compiled in place.
You could try chowning the SeaMonkey executable or launching it from a sh session with your ownership and test if that helps. Another option is to use some program to strip the EAs of the files. If you find chowning or such works, please report.
Other then that, we're basically stuck with it unless libc is changed and when that was brought up years back, Knut refused as he had plans.  Unluckily Knut hasn't had time for OS/2 in a long time.
I see Dariusz has posted an idea too, no idea if a good idea

[Dariusz Piatkowski]

I see Dariusz has posted an idea too, no idea if a good idea

LOL...man this is why I have stuck with OS/2 over so many years (well, one of the reasons anyways), you always get the "opportunity" to find another way...

So here is what I did:

1) OS/2 file

Code: [Select]

-rw------- 1 root root     25602 Dec  6  2017 brp5470enc.ppd

2) NAS box file after being copied

Code: [Select]

[V:\public\raw\software]ls -ltr
-rw-rw-rw- 1 root root    25602 Dec  6  2017  brp5470enc.ppd

So at least here, given the Samba connection ID (root/admin) and therefore the Samba server permissions, the TARGET fs file inherits the ID's permissions.

[David McKenna]

 Thanks for the tips guys! I used Dariusz' approach and indeed, if I log on to the SAMBA server (that is running on an OS/2 machine) share as 'root' (instead of my typical user ID), then when copied the file is saved with read and write permissions for anyone else too. The user ID I was using was also in the 'admin' group (as is 'root'), but I guess that is not enough...

Regards,

[David McKenna]

 Well... not quite. I went to the server and checked the permissions on the file I copied, and they are still -rw-------. So that means only someone logged on as root can get to them (and show then as -rw-rw-rw-). I'll try Dave's approach next...

Regards,

[David McKenna]

 Chowning the SeaMonkey executable didn't help - it still saves files as '-rw------- root root'. When I think about it, probably by design the only way to deal with this is chmod the files to give them universal access. Too bad can't get SeaMonkey to do it when downloading...

Regards,

[Dave Yeo]

I can't imagine how SeaMonkey could change the ownership when downloading besides changing its owner, too bad su is broken.
Simplest may be to just change the ownership of the downloaded files, something like

Code: [Select]

chown -cR dave Downloads/ executed in the parent of Downloads/ gives this,

Code: [Select]

Z:\Mozprofiles\Downloads>ls -l to*
-rwxr-xr-x 1 dave root 90333 Feb  2  2021 tolower_ld.exe
-rw------- 1 dave root  3695 Feb  2  2021 tolower.c
-rw------- 1 dave root   696 Feb  2  2021 tolower.mak
-rw------- 1 dave root  3695 Feb  2  2021 toupper.c
-rwxr-xr-x 1 dave root 90333 Feb  2  2021 toupper.exe
-rwxrwxrwx 1 dave root  6228 Feb  2  2021 TOLOWER.EXE


[Dave Yeo]

OK, thinking about it some more, SeaMonkey (and FF and TB) is broken when setting the permissions as the downloaded files should be at least readable by all users or better, use the umask of the parent directory. Seems we don't have the umask command and setting the parent directories permissions to, for example 777 doesn't help.
I found https://bugzilla.mozilla.org/show_bug.cgi?id=120679 which should have at least changed OS/2's directory file permissions to 0777 instead of 0644 but didn't seem to have been applied to nsLocalFileOS2.cpp. I can change that easy enough. The other problem is that for files it has this comment,

Code: [Select]

// the only Unix-style permission OS/2 knows is whether a file i
// writable;  as a matter of policy, a browser shouldn't be able
// to change any of the other DOS-style attributes;  to enforce
// this, we use DosSetPathInfo() rather than chmod()

I can probably fix this too by borrowing the Unix code. Have to think on it. it'll also require rebuilding everything once working.
To be considered, what permissions should files have and should tmp files be treated differently? On Unix, files stored in /tmp might have sensitive info, lets say a personalized PDF, so is stored only readable by the owner. Does this matter on OS/2? Seems to me not so perhaps best to just set all permissions as readable/writeable and executable by everyone?

[David McKenna]

Dave,

  I would think at least readable and writable by everyone, and executable too if an executable file, but I am no expert on this for sure.. thanks for even considering fixing this!

Regards,

[Dariusz Piatkowski]

You know...there is one more thing I came across while looking into the LIBC errors I am starting to regularly see now.

Here is what I found at the LIBCx Github (https://github.com/bitwiseworks/libcx):

EXPERIMENTAL. Automatic setting of the Unix user ID at process startup to an ID of a user specified with the LOGNAME or USER environment variable if a match in the passwd database is found for it. This has a numbef of side effects, e.g. all files and directories created by kLIBC functions will have an UID and GID of the specified user rathar than root. Also Unix programs will see the correct user via getuid() and other APIs which in particular will make some tools (e.g. yum) complain about the lack of root priveleges. For this reason this functionality is disabled by default and can be enabled by setting LIBCX_SETUID=1 in the environment.

David,
Worth a try? You could try enabling this just for the Seamonkey session itself, so you'd need to start from a CMD and have the environment variables set there before you load Seamonkey.

[David McKenna]

 Hi Dariusz,

 Tried using libcx_setuid=1, and it seems to work in that when a file is downloaded with SeaMonkey it now has the permission: '-rw------- DaveM root'. But that really doesn't solve the issue - what I want is for the files to be accessible to anyone who uses the share, not just me. In other words, the permissions need to be: '-rw-rw-rw- root root'. Only SeaMonkey can set that at download time (or use 'chmod' to change it afterwards).

Regards,

[David McKenna]

 Dave,

 Just to check for comparison, I downloaded a zip file from Hobbes using the QT5 Simplebrowser. The permissions on it were: '-rw-r--r-- root root'. Maybe that makes the most sense for downloaded files? I would think '-rwxr-xr-x root root' would also be appropriate for an executable file. And it seems from your example above that is what the exceptions you mention show too.

Regards,

[Dave Yeo]

Yes, either one should be fine. Turns out the code is more complex then I first thought, have to experiment and maybe ask for help.

[Alex Taylor]

In my QE editor and a few other programs, I simply make sure that new files are created without EAs. 

More precisely, because libc creates these file permission EAs on a new file automatically, my save routines all have some logic to immediately delete them if the file was new. (I don't do that when updating an existing file because the user might actually have set them on purpose.)

e.g.

Code: [Select]

    if ( !fileExists ) {
#ifdef __OS2__
        // If this is a new file, get rid of the useless default EAs added by klibc
        deleteEA( pszFileName, (PCSZ) "UID");
        deleteEA( pszFileName, (PCSZ) "GID");
        deleteEA( pszFileName, (PCSZ) "MODE");
        deleteEA( pszFileName, (PCSZ) "INO");
        deleteEA( pszFileName, (PCSZ) "RDEV");
        deleteEA( pszFileName, (PCSZ) "GEN");
        deleteEA( pszFileName, (PCSZ) "FLAGS");
#endif
    }


Code: [Select]

unsigned long deleteEA( char *pszPathName, const char *pszEAName )
{
    PFEA2LIST pFEA2List = NULL;
    PFEA2     pFEA2 = NULL;
    EAOP2     eaop2 = {0};
    size_t    cb = 0;
    APIRET    rc = ERROR_NOT_ENOUGH_MEMORY;

    cb = sizeof( FEA2LIST ) + strlen( pszEAName );
    pFEA2List = (PFEA2LIST) calloc( cb, 1 );
    if ( pFEA2List ) {
        pFEA2List->cbList = cb;
        pFEA2 = pFEA2List->list;
        pFEA2->cbName = (BYTE) strlen( pszEAName );
        strcpy( pFEA2->szName, pszEAName );
        pFEA2->cbValue = 0;

        eaop2.fpFEA2List = pFEA2List;
        rc = DosSetPathInfo( (PCSZ) pszPathName, FIL_QUERYEASIZE,
                             (PBYTE) &eaop2, sizeof( eaop2 ), DSPI_WRTTHRU );
        free( pFEA2List );
    }
    return (unsigned long) rc;
}