Rox-filer as ‘root’ can run smoothly antiX-23

Forum Forums General Software Rox-filer as ‘root’ can run smoothly antiX-23

  • This topic has 18 replies, 6 voices, and was last updated Feb 18-9:11 pm by Brian Masinick.
Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
    Posts
  • #132929
    Member
    tamix

      Using the latest antiX23.1 version using rox-icewm desktop,

      I have reported on this before, but I am wondering if this is the expected behavior.

      If I open a rox-filer window as root, I cannot open a text file to edit.

      my experiences here so far with the above rox-filer problem
      Opening files in rox-filer as root only works if rox is opened from a root-terminal.
      It also works from the menu, but only once, if it is the first application for which the root password has been entered. If rox is then immediately closed and opened again, files can no longer be opened.

      RO LiveUSB antiX-23_x64-full (sysv)

      @caprea and @calciumsodium I think I got a suitable solution for that problem.

      Please check out the attached file desktop-defaults-run-test-v1.zip below. A readme file can explain a few things.

      Hope it helps.

      They call me anartista.
      « If the users don't control the program, the program controls the users. » - rms

      #133014
      Member
      anti-apXos

        Your readme didn’t really explain much, but looking at the patch file, I guess the main change is using ‘eval’ instead of ‘exec’ in the final call.

        I tried your patched version like this

        su-to-root -X -c './desktop-defaults-run -fm'
        

        in a rox-icewm session, but I still get the same behavior as with the unpatched desktop-defaults-run or as using

        su-to-root -X -c rox-filer
        

        Is there some other way this is supposed to work?

        Looking into this issue some more, I think the problem is that rox-filer automatically forks itself to the background, which makes gksu think the program was ended and clean up the temporary .Xauthority file it created.

        Rox offers a commandline switch (–new) to disable the forking. Using that with su-to-root or gksu fixes the problem for me

        su-to-root -X -c 'rox-filer --new'
        

        You can compare ‘pstree’ outputs of rox-filer started with and without the ‘–new’ switch to see the difference.

        #133017
        Member
        calciumsodium

          Thank you @anti-apXos, your solution solves the problem for me:

          
          gksu 'rox --new'
          

          Hi @tamix,
          Your script did not work for me.

          #133025
          Moderator
          Brian Masinick

            Using the latest antiX23.1 version using rox-icewm desktop,

            I have reported on this before, but I am wondering if this is the expected behavior.

            If I open a rox-filer window as root, I cannot open a text file to edit.

            my experiences here so far with the above rox-filer problem
            Opening files in rox-filer as root only works if rox is opened from a root-terminal.
            It also works from the menu, but only once, if it is the first application for which the root password has been entered. If rox is then immediately closed and opened again, files can no longer be opened.

            RO LiveUSB antiX-23_x64-full (sysv)


            @caprea
            and @calciumsodium I think I got a suitable solution for that problem.

            Please check out the attached file desktop-defaults-run-test-v1.zip below. A readme file can explain a few things.

            Hope it helps.

            I got this to work very nicely and I was also able to follow along in the readme file and try a few things out; I changed the hidden text file default editor; that worked too, switching back and forth between leafpad, nano and geany.

            To get it to work I simply followed the readme instructions to download, unzip, patch, move files, change ownership/permissions, then execute using option #3; worked fine for me using this method.

            --
            Brian Masinick

            #133095
            Moderator
            caprea

              @anti-apXos, yes, that works here too.
              su-to-root -X -c 'rox-filer --new'
              or
              gksu 'rox --new

              ————————-

              Unfortunately your script didn’t work for me either @tamix

              • This reply was modified 2 weeks, 2 days ago by caprea.
              #133231
              Member
              tamix

                RO LiveUSB antiX-23_x64-full (sysv)

                One can just wonder why people always look for complications.

                Starter:

                $ gksu 'rox --new' &
                $ gksu 'rox --new' &
                $ gksu 'rox --new' &
                $ pstree -a | grep -w rox-filer
                  |-rox --pinboard=antiX-icewm
                  |   |   |-gksu rox --new
                  |   |   |   '-sudo -H -S -p GNOME_SUDO_PASS -u root -- rox --new
                  |   |   |       '-rox --new
                  |   |   |-gksu rox --new
                  |   |   |   '-sudo -H -S -p GNOME_SUDO_PASS -u root -- rox --new
                  |   |   |       '-rox --new
                  |   |   '-gksu rox --new
                  |   |       '-sudo -H -S -p GNOME_SUDO_PASS -u root -- rox --new
                  |   |           '-rox --new

                Main course:

                $ su-to-root -X -c 'rox-filer --new' &
                $ su-to-root -X -c 'rox-filer --new' &
                $ su-to-root -X -c 'rox-filer --new' &
                $ pstree -a | grep -w rox-filer
                  |   |   |-su-to-root /usr/bin/su-to-root -X -c rox-filer --new
                  |   |   |   '-gksu -u root rox-filer --new
                  |   |   |       '-sudo -H -S -p GNOME_SUDO_PASS -u root -- rox-filer --new
                  |   |   |           '-rox-filer --new
                  |   |   |-su-to-root /usr/bin/su-to-root -X -c rox-filer --new
                  |   |   |   '-gksu -u root rox-filer --new
                  |   |   |       '-sudo -H -S -p GNOME_SUDO_PASS -u root -- rox-filer --new
                  |   |   |           '-rox-filer --new
                  |   |   '-su-to-root /usr/bin/su-to-root -X -c rox-filer --new
                  |   |       '-gksu -u root rox-filer --new
                  |   |           '-sudo -H -S -p GNOME_SUDO_PASS -u root -- rox-filer --new
                  |   |               '-rox-filer --new

                Dessert #1:

                $ sudo rox-filer
                $ sudo rox-filer
                $ sudo rox-filer
                $ pstree -a | grep -w rox-filer
                  |-rox-filer
                $ ps -ef | grep -w rox-filer
                root       30687       1  0 22:25 ?        00:00:00 rox-filer

                Dessert #2:

                $ sudo rox
                $ sudo rox
                $ sudo rox
                $ pstree -a | grep -w rox
                  |-rox
                  |-rox --pinboard=antiX-icewm

                The two latter work in my environment, patch or not patch. Since multiple instances of Rox-filer are the core of that software, as a modest Unixian I prefer by far light desserts. Good appetite.

                (I replaced backquotes with simple quotes inside the blocks.)

                • This reply was modified 2 weeks, 1 day ago by tamix.
                • This reply was modified 2 weeks, 1 day ago by tamix.

                They call me anartista.
                « If the users don't control the program, the program controls the users. » - rms

                #133247
                Member
                anti-apXos

                  The two latter work in my environment, patch or not patch. Since multiple instances of Rox-filer are the core of that software, as a modest Unixian I prefer by far light desserts. Good appetite.

                  ‘sudo rox’ also works for me. The issue is when using gksu or su-to-root to start rox as root with a graphical password entry, such as from the iceWM menu. That leads to a rox instance that’s not able to open any files, which is the problem originally described in the other thread you quoted in your first post.

                  I thought that’s what your patch to desktop-session-run was meant to address, but maybe I misunderstood something.

                  I also wonder if you and Brian and maybe some others might possibly have

                  Default timestamp_timeout=0
                  

                  set in your /etc/sudoers file so that you have to enter a password every time you use sudo/gksu and so you don’t ever see the larger problem with the rox-as-root menu entry not being able to open anything.

                  For me, using the “rox-filer –new” option is good enough because I won’t usually need more than one rox-as-root window open and even then only for a little while anyway.

                  • This reply was modified 2 weeks, 1 day ago by anti-apXos.
                  #133298
                  Member
                  tamix

                    I thought that’s what your patch to desktop-session-run was meant to address, but maybe I misunderstood something.

                    No, @anti-apXos, you misunderstood nothing. Thanks a lot for your interesting remarks.

                    If one refers to a simple terminal interface, using sudo is the right way and is sufficient.

                    If one refers to the graphical user interface (menus, etc) then I think my patch might be the beginning of a solution provided one gets some constructive echos from users, according to their own OS environments, flavours, and so on. I still have to mitigate the initial readme file, which needs a review. I shall post a second version shortly, one for antiX-23 and one for antiX-21. But in my opinion, the topic should go beyond the point of a specific patch as it is proposed here.

                    I also wonder if you and Brian and maybe some others might possibly have

                    Default timestamp_timeout=0
                    

                    No, I have no timestamp_timeout set on my side. I just use sudo -k if I encounter a freezing event inside rox-filer because, in this case, I know it is useless to insist. But whenever I use sudo rox-filer I never have to run sudo -k before or to use a configuration file.

                    What I have been observing for a few days about that matter is really strange. I would say: « Il y a un loup » (lit. « there is a wolf »), an expression used in the construction industry to say there is a defect due to a bad workmanship.

                    Besides, I am living a very similar experience described in that thread where, unfortunately, nobody has poked his/her nose until now. In my mind, it is a matter of unstable and unexplained factors in the Rox-IceWM context too.

                    Back to this thread. I am fundamentally convinced that there is here something unstable, perhaps due to one or several events in the antiX user interface. It is indeed a paradox: the antiX user interface is very, very, very rich but it is also really fragile due to that feature precisely. Fortunately, antiX is highly robust on many other aspects.

                    In the interface, one can see pretty numerous sequences of all kinds like “pointers to pointers to pointers, etc.”. A surplus of pointers. When I talk about “pointers”, I mean of course indirections. Add to that chain some specific “context(s)” for each pointer, add also various “parameter(s)” for each context of pointer, etc. Add things like cache managements, memory managements, refreshing, user actions or events, unknown environments… Add black boxes in the monitoring process that might help discover potential bugs. Add …the great variety of users and the lack of close/remote control when questions get harder and harder in some very specific cases.

                    Are we going too far? Will we go too far? I do not know. Sometimes I get headaches. The more we add parameters or options – certainly for the best reasons – the more we make the set fragile, step by step, unknowingly. Let us consider the list below which is far from being exhaustive:

                    1. IceWm
                    2. Rox / Rox-filer
                    3. su-to-root
                    4. gksu
                    5. sudo
                    6. shell scripts (sh, bash)
                    7. OS binaries
                    8. customized menus

                    If you tell me: su-to-root 'rox-filer --new' is ok.
                    Well, why not? But I could also reply: Please stop, « there is a wolf », so I cannot follow you because the chain mentioned above which may be useful in a debugging context is not appropriate in the antixer’s daily life (at least in mine). Of course, anti-apXos, we are entirely free to do whatever we want to do in our desktop, it’s not a point of discussion 😉

                    I you tell me: ‘–new’ then I would tell you: ‘–new’ or not, the environment is still unstable and we should gather our efforts to understand why. My modest contribution with the patch was to point to possible causes of instability detected in a script, merely because I did run the right tests. But I suspect other points of instability, namely the Rox-IceWM cache management as well as the (dubious?) su-to-root script as it is executed in that context. Well « there might be a pack of wolves » as a matter of fact 🙁

                    I may be wrong but I cannot consider the following process chain su-to-root -> su-to-root -> gksu -> sudo -> app
                    a clear sequence from the simple point of view of process children or process scheduling. Especially when the sequence is to be literally duplicated once, ten times, or many more.

                    After all, we should proceed according Ockham’s razor, technically and scientifically. It would be a good vital lead.

                    • This reply was modified 2 weeks ago by tamix.

                    They call me anartista.
                    « If the users don't control the program, the program controls the users. » - rms

                    #133310
                    Member
                    anti-apXos

                      su-to-root is a wrapper script that searches for different ways of invoking superuser. It’s not necessary, but I assume it’s used in antiX menus and desktop files so that everything will still work if a user installs, for example, pksu instead of gksu.

                      gksu is sort of a frontend for su/sudo with a graphical login and some supposed security enhancements like making a temporary .Xauthority environment. It’s also not necessary since you can of course just use sudo on a terminal, but the graphical password entry is more convenient for a lot of users.

                      So in order to have a flexible and convenient system for starting root processes from a menu this su-to-root > gksu > sudo > aplication process chain is required. It may seem “impure” or something, but most people don’t care and you’re always free to change or avoid it on your own system.

                      The fact that starting rox-as-root without “–new”, using just

                      su-to-root -X -c rox-filer
                      

                      doesn’t leave that chain is the whole problem, as far as I can tell. By default (without “–new”), rox forks itself to the background. When that gappens, gksu sees the process as ended, so it terminates and deletes the .Xauthority file it created in /tmp. That leaves the forked rox-as-root instance without any .Xauthority, so it can no longer launch other processes. At least, I’m pretty sure that’s what’s going on.

                      I don’t have any other distros installed to test with easily, but I don’t think this is a problem introduced by antiX either. It should be the same on any system when starting rox with gksu. Others like pksu may work differently, though, I’m not sure.

                      #133346
                      Member
                      tamix

                        RO LiveUSB antiX-23_x64-full (sysv)

                        @anti-apXos I am quite willing to hear every good explanation, no problem. It looks like you are looping on the same arguments given in your first message in this thread though. It means you have convictions.

                        If this is correct, then would you please explain why I cannot come to the result below by the means of a script simply patched only? There is no miracle, just rationality.

                        Note I did not touch anything else in my environment – except the patched file. And I can do the same thing with leafpad if the root’s editor.desktop@ was linked to leafpad.desktop. Please have a glance at the screenshot attached below.

                        Patch applied currently.

                        First on the terminal: $ sudo -k

                        Three times this path in the antiX menu in the same session:

                        1. Applications -> System -> ROX Filer as root
                        Open .bashrc

                        2. Applications -> System -> ROX Filer as root
                        Open .bashrc

                        3. Applications -> System -> ROX Filer as root
                        Open .bashrc

                        Back to the the terminal:

                        $ pstree -a | grep -w rox-filer
                          |-rox-filer
                          |               '-su-to-root /usr/bin/su-to-root -X -c rox-filer
                          |                   '-gksu -u root rox-filer
                        
                        
                        $ md5sum /usr/local/bin/desktop-defaults-run
                        bfb51757cc186575e8b41ef64eab1796  /usr/local/bin/desktop-defaults-run

                        Hope it helps.

                        • This reply was modified 2 weeks ago by tamix.
                        • This reply was modified 2 weeks ago by tamix.

                        They call me anartista.
                        « If the users don't control the program, the program controls the users. » - rms

                        #133350
                        Member
                        abc-nix

                          I think people here are NOT on the same page. The OP is specifically writing on every post their environment.

                          RO LiveUSB antiX-23_x64-full (sysv)

                          Meaning, it is not antiX 23.1 (RC or testing or beta or any of them), it is not antiX 23.X runit, it is not antiX 23 live updated/remastered, etc. It is a read-only live USB of antiX 23 full sysvinit release. Their environment doesn’t match ours, so their results cannot match ours. We either test on their same specific environment or wait for the final antiX 23.1 release so we are all on the same page.

                          • This reply was modified 2 weeks ago by abc-nix.
                          #133354
                          Member
                          tamix

                            I think people here are NOT on the same page. The OP is specifically writing on every post their environment.

                            RO LiveUSB antiX-23_x64-full (sysv)

                            Meaning, it is not antiX 23.1 (RC or testing or beta or any of them), it is not antiX 23.X runit, it is not antiX 23 live updated/remastered, etc. It is a read-only live USB of antiX 23 full sysvinit release. Their environment doesn’t match ours, so their results cannot match ours. We either test on their same specific environment or wait for the final antiX 23.1 release so we are all on the same page.

                            Thanks @abc-nix. I think you are quite right.

                            I also noticed that nobody except me specified in this thread his/her currently used antiX flavour. This certainly has led to confusion.

                            Regards.

                            EDIT: That was also what I was about to ask for precisely.

                            • This reply was modified 2 weeks ago by tamix.

                            They call me anartista.
                            « If the users don't control the program, the program controls the users. » - rms

                            #133361
                            Member
                            anti-apXos

                              Meaning, it is not antiX 23.1 (RC or testing or beta or any of them), it is not antiX 23.X runit, it is not antiX 23 live updated/remastered, etc. It is a read-only live USB of antiX 23 full sysvinit release. Their environment doesn’t match ours, so their results cannot match ours. We either test on their same specific environment or wait for the final antiX 23.1 release so we are all on the same page.

                              I do get the results @Tamix described, though, so I don’t think this is the issue.

                              If you enter “sudo -k” first (or if it’s been long enough for the timestamp_timeout set in sudoers to expire) so that a password has to be entered, then

                              su-to-root -X -c rox-filer
                              

                              does produce a (sort of) working rox-as-root instance. I say only sort of working since using terminal-based apps to open files still doesn’t work. Neither does just opening or switching to a terminal from the rox Window menu.

                              This was all described by @Caprea and others in the previous discussion that @Tamix quoted some comments from. Other comments there mentioned that the same was true at least back to antiX 21. My installs that I’ve found it on include 23 and 23.1, full and frugal with runit and just confirmed also with s6-rc in the Valentine’s ISO.

                              I don’t think it’s to do with the antiX version or even antiX at all.

                              @Tamix, if you check the full pstree output after your above procedure, you’ll see that su-to-root, gksu, sudo are still running in this case even though rox-filer did fork. Also, looking in the /tmp directory, the .Xauthority created by gksu is still there.

                              I cannot explain why that only happens when you have to enter a password for gksu and not when gksu relies on a timestamped authentication, but I do still suspect it’s gksu behavior, not anything specific to antiX. Someone would have to test in another distro with gksu and rox to see, though, I guess.

                              • This reply was modified 2 weeks ago by anti-apXos.
                              #133604
                              Member
                              tamix

                                @Masinick I am sincerely sorry for delaying my reply. Please don’t take it amiss.

                                I got this to work very nicely and I was also able to follow along in the readme file and try a few things out; I changed the hidden text file default editor; that worked too, switching back and forth between leafpad, nano and geany.

                                As a matter of fact, this is the fully positive first feedback I found in this RFAR thread. I did appreciate that you made every effort to run tests exhaustively in the way I suggested, then to run extra tests of your own. And you have also written how you proceeded. This is comforting, you know. So I presume the desktop screenshot I posted in a subsequent message can be quite familiar to you.

                                The patch currently proposed does not mean the problem is solved at all. Although the 3 standard corrections are justified and tested in a given context, it is only a temporary workaround that also “fails” in some second-trial sessions. In general, I am no shell script rewriter, it’s not my goal at all. I just like facing a few issues I see here and there. Not everything can be explained from scratch through a readme file where I just tried to be concise. Complexity does not mean necessarily that complications are looked for. It is a fact that RFAR is rather complex – and hazardous – from the point of view of a linux multi-thread behaviour.

                                I plan to review the readme attached in the patch. My current observations are not over, I still need to explore what’s going on. By the way, an antiX-21 patch release is on the way shortly, in case some people are interested.

                                Regards.

                                P.S. On the day I opened the thread, I did not realize that the loooong sub-discussion on there had been continued far after the pages 16 & 17. Step after step, I’ve just come up to page 23 today, and I presume the discussion still goes on after… Apparently many people did feel committed on that problem, very interesting. This explains why there may have been redundancy in the contents of the thread I directly posted from General -> Software. This may also explain why people are “tired”. Well I did not do it on purpose: I am used to working in offline terminal sessions, most of the time. Offline and hopefully open-minded 🙂

                                They call me anartista.
                                « If the users don't control the program, the program controls the users. » - rms

                                #133605
                                Member
                                tamix

                                  I think people here are NOT on the same page. The OP is specifically writing on every post their environment.

                                  People here are quite on the same page. I borrowed the first two user quotations from a thread in antiX-development › Development but I opened the current thread from General › Software in the perspective of a larger multi-context discussion.

                                  They call me anartista.
                                  « If the users don't control the program, the program controls the users. » - rms

                                Viewing 15 posts - 1 through 15 (of 19 total)
                                • You must be logged in to reply to this topic.