Loading ...
Sorry, an error occurred while loading the content.

Re: [nslu2-linux] Using fallback suid method

Expand Messages
  • Mike Westerhof (mwester)
    ... This was discussed on the mailing list earlier -- search the archives on yahoo and you should find the details. It s a busybox thing, and IIRC one simply
    Message 1 of 5 , Jun 5, 2009
    • 0 Attachment
      Corneliu Doban wrote:
      > Hi,
      >
      > I'm getting the following message every time I login on the SugOS 5.3: Using fallback suid method.

      This was discussed on the mailing list earlier -- search the archives on
      yahoo and you should find the details. It's a busybox thing, and IIRC
      one simply has to create a file in /etc with the appropriate suid
      information (an empty file is all it needs to behave like a normal Linux
      system).

      Of course, if you check the busybox website and archives for info on
      this feature, you might find that feature to be useful (I thought it
      might be, which is why it's enabled in the first place (although it
      would have been nice if the default image had the config file created,
      at least as an empty file)).

      >
      > Also the following 2 errors are logged:
      > Jun 1 19:19:01 slugos sshd[1276]: error: Could not get shadow information for

      SlugOS does not implement a shadow password. Off the top of my head I
      don't recall if one can disable SSHD's checking for the shadow passwd
      file, but the message is quite benign so nobody has ever worried about
      it. I'd recommend ignoring it as well.

      > Jun 1 19:19:01 slugos sshd[1280]: error: setlogin failed: Function not implemented

      This is due to something in libc -- again I don't recall the details,
      you will find it discussed in the archives for the mailing lists on
      yahoo. Or you can search the sshd mailing list archives; this message
      is not unique to SlugOS. It too can be safely ignored; it has to do
      with unimplemented logging stuff, if memory serves.

      >
      > I don't remember seeing this after installing the SlugOS, so I might have caused it.
      > Is any of you seeing it, or you might know the fix?

      No fix required. The only common thing is the creation of the empty
      file in /etc that's described either on the wiki or in the mailing list
      archives, but that doesn't change any behavior, it just gets rid of that
      annoying message.


      > Thanks,
      > Corneliu

      Mike (mwester)
    • slackline
      ... I ve just encountered this in my upgrade to 5.3 after having created a new user account (messages reported when first logging in). I searched the
      Message 2 of 5 , Jun 30, 2009
      • 0 Attachment
        --- In nslu2-linux@yahoogroups.com, "Mike Westerhof (mwester)" <mwester@...> wrote:
        >
        > Corneliu Doban wrote:
        > > Hi,
        > >
        > > I'm getting the following message every time I login on the SugOS 5.3: Using fallback suid method.
        >
        > This was discussed on the mailing list earlier -- search the archives on
        > yahoo and you should find the details. It's a busybox thing, and IIRC
        > one simply has to create a file in /etc with the appropriate suid
        > information (an empty file is all it needs to behave like a normal Linux
        > system).
        >
        > Of course, if you check the busybox website and archives for info on
        > this feature, you might find that feature to be useful (I thought it
        > might be, which is why it's enabled in the first place (although it
        > would have been nice if the default image had the config file created,
        > at least as an empty file)).
        >

        I've just encountered this in my upgrade to 5.3 after having created a new user account (messages reported when first logging in).

        I searched the nslu2-linux archives (on nabble and yahoo and couldn't find anything other than this) and busybox archives and found this pointer --> http://lists.busybox.net/pipermail/busybox/2003-November/009851.html

        Downloaded the source and 'make menuconfig' to get into the help which reads as follows (posting here so that the solution can, hopefully, be found in the archives here)...

        CONFIG_FEATURE_SUID_CONFIG:

        Allow the SUID / SGID state of an applet to be determined at runtime
        by checking /etc/busybox.conf. (This is sort of a poor man's sudo.)
        The format of this file is as follows:

        <applet> = [Ssx-][Ssx-][x-] (<username>|<uid>).(<groupname>|<gid>)

        An example might help:

        [SUID]
        su = ssx root.0 # applet su can be run by anyone and runs with
        # euid=0/egid=0
        su = ssx # exactly the same

        mount = sx- root.disk # applet mount can be run by root and members
        # of group disk and runs with euid=0

        cp = --- # disable applet cp for everyone

        The file has to be owned by user root, group root and has to be
        writeable only by root:│
        (chown 0.0 /etc/busybox.conf; chmod 600 /etc/busybox.conf)
        The busybox executable has to be owned by user root, group
        root and has to be setuid root for this to work:
        (chown 0.0 /bin/busybox; chmod 4755 /bin/busybox)

        Robert 'sandman' Griebl has more information here:
        <url: http://www.softforge.de/bb/suid.html >.


        I created the file (leaving it blank) and changed ownership and permissions as per above instructions, but no joy (yet), haven't tried rebooting yet though (will have to wait till I get home). Will update if I get it resolved.

        Neil
      • slackline
        ... Ok, I seem to have solved this using the solution suggested at http://lists.busybox.net/pipermail/busybox/2003-March/008115.html Basically I needed to
        Message 3 of 5 , Jul 2 6:55 AM
        • 0 Attachment
          --- In nslu2-linux@yahoogroups.com, "slackline" <nshephard@...> wrote:
          >

          > I've just encountered this in my upgrade to 5.3 after having created a new user account (messages reported when first logging in).
          >
          > I searched the nslu2-linux archives (on nabble and yahoo and couldn't find anything other than this) and busybox archives and found this pointer --> http://lists.busybox.net/pipermail/busybox/2003-November/009851.html
          >
          > Downloaded the source and 'make menuconfig' to get into the help which reads as follows (posting here so that the solution can, hopefully, be found in the archives here)...
          >
          > CONFIG_FEATURE_SUID_CONFIG:
          >
          > Allow the SUID / SGID state of an applet to be determined at runtime
          > by checking /etc/busybox.conf. (This is sort of a poor man's sudo.)
          > The format of this file is as follows:
          >
          > <applet> = [Ssx-][Ssx-][x-] (<username>|<uid>).(<groupname>|<gid>)
          >
          > An example might help:
          >
          > [SUID]
          > su = ssx root.0 # applet su can be run by anyone and runs with
          > # euid=0/egid=0
          > su = ssx # exactly the same
          > │
          > mount = sx- root.disk # applet mount can be run by root and members
          > # of group disk and runs with euid=0
          >
          > cp = --- # disable applet cp for everyone
          >
          > The file has to be owned by user root, group root and has to be
          > writeable only by root:│
          > (chown 0.0 /etc/busybox.conf; chmod 600 /etc/busybox.conf)
          > The busybox executable has to be owned by user root, group
          > root and has to be setuid root for this to work:
          > (chown 0.0 /bin/busybox; chmod 4755 /bin/busybox)
          >
          > Robert 'sandman' Griebl has more information here:
          > <url: http://www.softforge.de/bb/suid.html >.
          >
          >
          > I created the file (leaving it blank) and changed ownership and permissions as per above instructions, but no joy (yet), haven't tried rebooting yet though (will have to wait till I get home). Will update if I get it resolved.
          >

          Ok, I seem to have solved this using the solution suggested at http://lists.busybox.net/pipermail/busybox/2003-March/008115.html

          Basically I needed to change the busybox binary such that the user or group ID is set on execution...

          chmod +s /bin/busybox

          Will find out later if this has resolved the permissions on mounting but suspect the suggested UUID approach is preferable (see http://tech.groups.yahoo.com/group/nslu2-linux/message/23830 )

          Neil
        • pasques
          touch /etc/busybox.conf (run as root) http://www.jamison.org/2010/12/21/fix-the-using-fallback-suid-method-error-message-on-busybox-nslu2/
          Message 4 of 5 , Sep 5, 2011
          • 0 Attachment
          Your message has been successfully submitted and would be delivered to recipients shortly.