Using fallback suid method Click to flag this post by CORNELIU DOBAN Jun 05, 2009; 07:03pm :: Rate this Message: - Use ratings to moderate (?) Reply | Print | View Threaded | Show Only this Message 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 Re: Using fallback suid method Click to flag this post by Mike Westerhof (mwester) Jun 05, 2009; 09:47pm :: Rate this Message: - Use ratings to moderate (?) Reply | Print | View Threaded | Show Only this Message 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) Re: Using fallback suid method Click to flag this post by Neil Shephard Jun 30, 2009; 11:10am :: Rate this Message: - Use ratings to moderate (?) Reply | Print | View Threaded | Show Only this Message --- In nslu2-linux@..., "Mike Westerhof (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)). > ... [show rest of quote] 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: = [Ssx-][Ssx-][x-] (|).(|) 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: . 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 Re: Using fallback suid method Click to flag this post by Neil Shephard Jul 02, 2009; 03:55pm :: Rate this Message: - Use ratings to moderate (?) Reply | Print | View Threaded | Show Only this Message --- In nslu2-linux@..., "slackline" 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: > > = [Ssx-][Ssx-][x-] (|).(|) > > 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: > . > > > 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. > ... [show rest of quote] 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 Re: Using fallback suid method Click to flag this post by pasques Sep 05, 2011; 07:12pm :: Rate this Message: - Use ratings to moderate (?) Reply | Print | View Threaded | Show Only this Message 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/