Using fallback suid method

[CORNELIU DOBAN]

Hi,

I'm getting the following message every time I login on the SugOS 5.3: Using fallback suid method.

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

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?

Thanks,
Corneliu

[Mike Westerhof (mwester)]

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)

[Neil Shephard]

--- In nslu2-linux@..., "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

[Neil Shephard]

--- In nslu2-linux@..., "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