OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: David McKenna on January 08, 2022, 03:10:56 pm

Title: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 08, 2022, 03:10:56 pm
 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,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dariusz Piatkowski on January 08, 2022, 06:37:43 pm
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.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 08, 2022, 06:46:20 pm
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 :)
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dariusz Piatkowski on January 08, 2022, 07:07:54 pm
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.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 08, 2022, 07:48:05 pm
 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,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 08, 2022, 08:03:52 pm
 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,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 08, 2022, 08:22:45 pm
 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,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 08, 2022, 09:28:16 pm
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
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 08, 2022, 10:42:48 pm
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 (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?
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 08, 2022, 10:51:55 pm
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,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dariusz Piatkowski on January 09, 2022, 02:53:01 am
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 (https://github.com/bitwiseworks/libcx)):

Quote
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.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 09, 2022, 02:41:36 pm
 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,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 09, 2022, 02:53:24 pm
 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,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 09, 2022, 05:14:41 pm
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.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Alex Taylor on January 10, 2022, 03:54:08 am
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;
}
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 10, 2022, 08:19:37 am
Unluckily the code paths are quite complex. Possibly class TypeEaEnumerator could be extended to delete those EAs if I had the skills to do it and if they don't get added somewhere else later.
While in here, I should try to figure out where the .TYPE EA (stores the download URL) is getting eaten. Perhaps we could save it and get rid of the other EAs at the same time.
For now, it seems simpler to just change the default permissions from 0600 to perhaps 0666.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Andreas Schnellbacher on January 10, 2022, 05:11:43 pm
Possibly class TypeEaEnumerator could be extended to delete those EAs
There exists eaclean by David A. for that. See https://88watts.net/software.html (https://88watts.net/software.html).
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 10, 2022, 11:03:12 pm
Possibly class TypeEaEnumerator could be extended to delete those EAs
There exists eaclean by David A. for that. See https://88watts.net/software.html (https://88watts.net/software.html).

Yes, that would be one workaround. class TypeEaEnumerator (written by Rich) is actually in xpcom\io\nsLocalFileOS2.cpp and it seems this stuff should go into that file, it is about 70KB with 2677 lines, perhaps too complex for me right now.
Looking, it seems that it is https://bugzilla.mozilla.org/show_bug.cgi?id=120679 (https://bugzilla.mozilla.org/show_bug.cgi?id=120679) that is the problem and has been since before Mozilla v1 if I understand correctly. As usual, this bug died due to bikeshedding. What I've tried is this,
Code: [Select]
diff --git a/netwerk/base/BackgroundFileSaver.cpp b/netwerk/base/BackgroundFileSaver.cpp
index f3cdccdffb..ea4be39887 100644
--- a/netwerk/base/BackgroundFileSaver.cpp
+++ b/netwerk/base/BackgroundFileSaver.cpp
@@ -623,7 +623,7 @@ BackgroundFileSaver::ProcessStateChange()
   nsCOMPtr<nsIOutputStream> outputStream;
   rv = NS_NewLocalFileOutputStream(getter_AddRefs(outputStream),
                                    mActualTarget,
-                                   PR_WRONLY | creationIoFlags, 0600);
+                                   PR_WRONLY | creationIoFlags, 0666);
   NS_ENSURE_SUCCESS(rv, rv);
 
   outputStream = NS_BufferOutputStream(outputStream, BUFFERED_IO_SIZE);
diff --git a/netwerk/base/nsDownloader.cpp b/netwerk/base/nsDownloader.cpp
index 3e6583ca67..5e4d455cb2 100644
--- a/netwerk/base/nsDownloader.cpp
+++ b/netwerk/base/nsDownloader.cpp
@@ -54,7 +54,7 @@ nsDownloader::OnStartRequest(nsIRequest *request, nsISupports *ctxt)
         rv = location->AppendNative(nsDependentCString(buf, 12));
         if (NS_FAILED(rv)) return rv;
 
-        rv = location->CreateUnique(nsIFile::NORMAL_FILE_TYPE, 0600);
+        rv = location->CreateUnique(nsIFile::NORMAL_FILE_TYPE, 0666);
         if (NS_FAILED(rv)) return rv;
 
         location.swap(mLocation);
diff --git a/netwerk/base/nsIncrementalDownload.cpp b/netwerk/base/nsIncrementalDownload.cpp
index 4250481fe4..cb1a8f4870 100644
--- a/netwerk/base/nsIncrementalDownload.cpp
+++ b/netwerk/base/nsIncrementalDownload.cpp
@@ -43,7 +43,7 @@ static nsresult
 WriteToFile(nsIFile *lf, const char *data, uint32_t len, int32_t flags)
 {
   PRFileDesc *fd;
-  int32_t mode = 0600;
+  int32_t mode = 0666;
   nsresult rv;
 #if defined(MOZ_WIDGET_GONK)
   // The sdcard on a B2G phone looks like:
which here results in (note the latest files)
Code: [Select]
-rw-r--r-- 1 root root    57948 Jan 10 12:58 3DLogicMinesweeper_1-0.zip
-rw------- 1 root root    13239 Jan 10 10:17 Battle_Ship_1-0.zip
-rw-r--r-- 1 root root     7605 Jan 10 12:16 BombSquad_1-0.zip
with random files downloaded from Hobbes.
Here's a lightly tested build, https://drive.google.com/file/d/1P3jWeDzldoUcKXYiv6uJ3kaV3c9-4GTt/view?usp=drivesdk (https://drive.google.com/file/d/1P3jWeDzldoUcKXYiv6uJ3kaV3c9-4GTt/view?usp=drivesdk)
Please test various ways of downloading and whether these permissions are good enough.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 11, 2022, 12:18:27 am
 Dave,

  Thanks for producing this new build! Everything I've tried so far produces '-rw-r--r-- root root' when downloaded whether .zip file, .exe file or .txt file. But it doesn't add up - if you are trying to use '0666' to set permissions, that should produce '-rw-rw-rw- root root'. '-rw-r--r--' = 0644, doesn't it? If you are going for a 'one size fits all' approach, maybe 0777 is the way to go to cover any possibility...

Regards,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 11, 2022, 01:14:36 am
Good observation, wonder if something is changing the permissions after being set where I patched? Have to experiment a bit more unless having it universally read-only is good enough. Louis figures 0777 is overkill.
Another question is email attachments.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Rich Walsh on January 11, 2022, 06:05:04 pm
wonder if something is changing the permissions after being set where I patched? Have to experiment a bit more unless having it universally read-only is good enough.

0666 is octal - are you sure you're not entering 0x666? The compiler will recognize octal if there's a leading zero (whence '0666'). FWIW... 0666 == 0x1B6.

Quote
Louis figures 0777 is overkill.

At the point where you are assigning permissions, doesn't the code know whether this is an executable or not?

Quote
Another question is email attachments.

There are no "other questions". This is OS/2: there are no users or groups, there is no security, none of the Unix considerations apply. I can look at and modify any file on my system, regardless of what someone's alien software says., These bogus Unix permissions should reflect that.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 11, 2022, 07:10:14 pm
wonder if something is changing the permissions after being set where I patched? Have to experiment a bit more unless having it universally read-only is good enough.

0666 is octal - are you sure you're not entering 0x666? The compiler will recognize octal if there's a leading zero (whence '0666'). FWIW... 0666 == 0x1B6.

No, I was entering octal, just made a bad assumption that somewhere the code was doing a chmod

Quote
Quote
Louis figures 0777 is overkill.

At the point where you are assigning permissions, doesn't the code know whether this is an executable or not?

No, I tried where it downloaded it and where the final moveto was done. At least now I found where that final moveto is now done (nsDownloadManager.cpp) so maybe can fix your EA .subject code.

Quote
Quote
Another question is email attachments.

There are no "other questions". This is OS/2: there are no users or groups, there is no security, none of the Unix considerations apply. I can look at and modify any file on my system, regardless of what someone's alien software says., These bogus Unix permissions should reflect that.

Yes, the permissions shouldn't matter, yet as David found, when other systems get involved, they do matter. This would also included accessing HPFS on Linux, which uses the same EA's for permissions.
Anyways for now I added chmod() to nsLocalFileOS2.cpp which seems to work. Perhaps I should try replacing it with Alex's code to delete the permissions as I agree that on OS/2 they're more of a hassle then a help.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 11, 2022, 07:14:20 pm
New test build at https://drive.google.com/file/d/1PPfJnqG_-6wgsRZq6A07fs0eHzusDXvs/view?usp=drivesdk (https://drive.google.com/file/d/1PPfJnqG_-6wgsRZq6A07fs0eHzusDXvs/view?usp=drivesdk).
For this I added chmod() to nsLocalFile::GetPermissionsOfLink() in nsLocalFileOS2.cpp. Might try Alex's suggestion as now I know where to add it I think.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on January 11, 2022, 10:09:24 pm
 Thanks again Dave! This one seems better - everything is downloaded with -rw-rw-rw- (0666) now. Would be interested if you could try Alex's idea too (which makes sense for OS/2)..

Regards,
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 18, 2022, 08:01:05 am
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;
}

Well, so far I've come up with this,
Code: [Select]
diff --git a/xpcom/io/nsLocalFileOS2.cpp b/xpcom/io/nsLocalFileOS2.cpp
index 32715473bd..bb772a8053 100644
--- a/xpcom/io/nsLocalFileOS2.cpp
+++ b/xpcom/io/nsLocalFileOS2.cpp
@@ -16,6 +16,7 @@
 #include "nsIDirectoryEnumerator.h"
 #include "nsIComponentManager.h"
 #include "prlink.h"
+#include "prmem.h"
 
 #include "nsTraceRefcnt.h"
 #include "nsReadableUtils.h"
@@ -233,6 +234,32 @@ static int isleadbyte(int c)
     return retval;
 }
 
+static nsresult deleteEA( char *pszPathName, char *pszEAName )
+  {
+      PFEA2LIST pFEA2List = NULL;
+      PFEA2     pFEA2 = NULL;
+      EAOP2     eaop2 = {0};
+      size_t    cb = 0;
+      APIRET    rc;
+
+      cb = sizeof( FEA2LIST ) + strlen( pszEAName );
+      pFEA2List = (PFEA2LIST) PR_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 );
+          PR_Free( pFEA2List );
+      }
+      if (rc != NO_ERROR)
+        return ConvertOS2Error(rc);
+  }
+
 //-----------------------------------------------------------------------------
 // nsDirEnumerator
 //-----------------------------------------------------------------------------
@@ -1956,6 +1983,15 @@ nsLocalFile::SetPermissions(uint32_t aPermissions)
 
     pathInfo.attrFile ^= FILE_READONLY;
 
+//  Get rid of the useless default EAs added by klibc
+    deleteEA( mWorkingPath.get(), (PCSZ) "UID");
+    deleteEA( mWorkingPath.get(), (PCSZ) "GID");
+    deleteEA( mWorkingPath.get(), (PCSZ) "MODE");
+    deleteEA( mWorkingPath.get(), (PCSZ) "INO");
+    deleteEA( mWorkingPath.get(), (PCSZ) "RDEV");
+    deleteEA( mWorkingPath.get(), (PCSZ) "GEN");
+    deleteEA( mWorkingPath.get(), (PCSZ) "FLAGS");
+
     rc = DosSetPathInfo(mWorkingPath.get(), FIL_STANDARD,
                         &pathInfo, sizeof(pathInfo), 0UL);

But the compiler isn't happy with converting the strings, (also the return type)
...
Code: [Select]
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp:1993:31: error: invalid conversion from 'const char_type*' {aka 'const char*'} to 'char*' [-fpermissive]
 1993 |     deleteEA( mWorkingPath.get(), (PCSZ) "FLAGS");
      |               ~~~~~~~~~~~~~~~~^~
      |                               |
      |                               const char_type* {aka const char*}
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp:237:33: note:   initializing argument 1 of 'nsresult deleteEA(char*, char*)'
  237 | static nsresult deleteEA( char *pszPathName, char *pszEAName )
      |                           ~~~~~~^~~~~~~~~~~
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp:1993:35: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 1993 |     deleteEA( mWorkingPath.get(), (PCSZ) "FLAGS");
      |                                   ^~~~~~~~~~~~~~
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp: In function 'nsresult deleteEA(char*, char*)':
Y:/work/cc45-git/mozilla/xpcom/io/nsLocalFileOS2.cpp:261:3: warning: control reaches end of non-void function [-Wreturn-type]
  261 |   }

Ideas?

Title: Re: SeaMonkey downloads and Unix permissions
Post by: Lars on January 18, 2022, 12:09:19 pm
Change both input params to "const char *", change function logic to ensure that you ALWAYS return a value (currently, you don't).
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 18, 2022, 06:47:02 pm
Thanks, that worked, except the EA's are still there. Probably need to strip them later when the tmp file gets moved to the permanent name in download.cpp
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Lars on January 19, 2022, 09:18:36 am
Thanks, that worked, except the EA's are still there. Probably need to strip them later when the tmp file gets moved to the permanent name in download.cpp

You should also preset the "rc" Variable with a decent value. Just like the initial example from Alexander Taylor.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on January 20, 2022, 03:00:04 am
Yes, I set it with NO_ERROR. At first I was worried about the scope of rc as it is used throughout the file.  Though thinking about it, I'm not sure what happens if there is an error, whether in the memory allocation or what DosQueryPathInfo() returns, perhaps it should have been passed somehow to the class, nsLocalFile::SetPermissions(uint32_t aPermissions).
https://github.com/bitwiseworks/mozilla-os2/blob/master/xpcom/io/nsLocalFileOS2.cpp (https://github.com/bitwiseworks/mozilla-os2/blob/master/xpcom/io/nsLocalFileOS2.cpp) about line 1931
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Lars on January 20, 2022, 08:54:11 am
Yes, I set it with NO_ERROR. At first I was worried about the scope of rc as it is used throughout the file.  Though thinking about it, I'm not sure what happens if there is an error, whether in the memory allocation or what DosQueryPathInfo() returns, perhaps it should have been passed somehow to the class, nsLocalFile::SetPermissions(uint32_t aPermissions).
https://github.com/bitwiseworks/mozilla-os2/blob/master/xpcom/io/nsLocalFileOS2.cpp (https://github.com/bitwiseworks/mozilla-os2/blob/master/xpcom/io/nsLocalFileOS2.cpp) about line 1931
In C, if you declare a variable in a block ("{" ... "}"), it is only known in that block (and effectively becomes a stack variable unless you declare it as "static" in which case it will be placed into the default data segment with a "madeup" unique name).
If you declare a variable outside of any block, then it is known throughout the whole source file (module). That way, you can have "rc" multiple times in a file but they are only declared locally.

The routine you are pointing to looks reasonable. Obviously, "NS_IMETHODIMP" is a define for something like "ULONG APIENTRY" or "unsigned long _System" or "unsigned long _cdecl" or such. In other words, a combination of return value and calling convention (you would need to search the header files for it ...).
By the way: "ConvertOS2Error" can also deal with a NO_ERROR = 0 on entry, therefore:
Code: [Select]
    if (rc)
        return ConvertOS2Error(rc);

    return NS_OK;
can just become:
Code: [Select]
     return ConvertOS2Error(rc);
Title: Re: SeaMonkey downloads and Unix permissions
Post by: Dave Yeo on June 19, 2022, 06:49:18 am
I seem to have lost interest in this some time back, getting old :)
Anyways, I've had to revert the chmod patch for now as it turns out it broke creating a new profile on a virgin install.
As these newer builds are going to be in AOS 5.1, for stabilties sake I've simply reverted the patch for now and hopefully will revisit. At this point the builds up to 06-06-22 have the chmod patch, making things like Samba happy but new profiles broken. The ones I'm currently uploading are the opposite, no chmod but new virgin profiles working.
Title: Re: SeaMonkey downloads and Unix permissions
Post by: David McKenna on June 24, 2022, 02:17:58 am
 Dave,

 Thanks for the head's-up on this. This problem was maddening for me, it took a long time to figure it out and it really was not acceptable, but I understand your situation, and you were able to fix it once notified, so I hope you can figure out a new solution eventually. Luckily, we have Dooble now (which seems to work OK). In the mean time I will stick with the fixed version.

Regards,