If the build was running under your userid, that file got created when
rxapi was launched during the build process. That's the file that is used
to ensure that only one copy of rxapi runs per user.

Rick

On Tue, Dec 25, 2018 at 5:09 AM P.O. Jonsson <oor...@jonases.se> wrote:

> Dear Erich,
>
> I was going into my user account on the Mac Mini Jenkins slave today and
> noticed a hidden file "*.ooRexx-5.0.0-64.lock*“ in my home directory
> (Users/po) Is this something that is coming out of the Jenkins build? How
> can the lock file be in my account? I have no ooRexx installation in that
> account and the machine wide installation has been removed. some time ago.
>
> Can you please explain the latest development with the locking and how it
> is intended to work? No criticism, just trying to understand.
>
> Von meinen Macbook gesendet
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
> Am 25.12.2018 um 00:39 schrieb Erich Steinböck <erich.steinbo...@gmail.com
> >:
>
> With a few typos fixed, this seems to work as expected, also in the
> discussed sudo scenario.
>
> also includes the login name in the file names
>>
> getuid() returns the id, not the name, so I had changed the %s to %d in
> the snprintf's
> I assume getting the name will require getpwuid() - if we want the name
> instead
>
> If no XDG_RUNTIME_DIR is set, this will be something like:
> ls -lda /tmp/.ooR*
> -rw-rw-rw- 1 jenkins  jenkins  0 Dec 24 23:19
> /tmp/.ooRexx-5.0.0-64-1002.lock
> srwxrwxrwx 1 jenkins  jenkins  0 Dec 24 23:49
> /tmp/.ooRexx-5.0.0-64-1002.service
> -rw-rw-rw- 1 www-data www-data 0 Dec 24 23:52 /tmp/.ooRexx-5.0.0-64-33.lock
> srwxrwxrwx 1 www-data www-data 0 Dec 24 23:49
> /tmp/.ooRexx-5.0.0-64-33.service
> I'm a bit concerned about the file permissions global RW bits, but to my
> surprise rm nevertheless refuses to remove both the lock and the service
> "file" (rm: cannot remove '/tmp/.ooRexx-5.0.0-64-1002.lock': Operation not
> permitted .. I don't understand why)
>
> There is one situation that will make rxapi fail to start: if a malicious
> user creates a simple file with the same name as the lock/service file of a
> user.  It might still be a good idea to check whether rxapi can create
> those files (XDG or /tmp) and if not, somehow (but how?) give an error
> indication "cannot create path/.ooRexx...service"
>
> On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire <object.r...@gmail.com>
> wrote:
>
>> Ok, from what Bob Martin posted, it sounds like the www-data login does
>> not have XDG variables set and also does not have write access to the home
>> directory. As others have said, using the home directory is probably a bad
>> idea because it could be network-mounted and using it would lock out users
>> on other machines. Here is a totally uncompiled and untested patch that
>> uses either the XDG_RUNTIME_DIR or /tmp for creating the files and also
>> includes the login name in the file names.
>>
>> Rick
>>
> <www-data-b.patch>_______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to