Re: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix
On Thu, Jun 26, 2014 at 04:47:04PM +0200, Denys Vlasenko wrote:
> On Thu, Jun 26, 2014 at 1:37 PM, Morten Kvistgaard
> wrote:
> >>> ...
> >>> execve("proc/self/exe", ["ftpd", "-l", "/"], [/* 9 vars */]) = -1
> >>> ENOENT (No such file or directory) ...
> >>
> >>This is strange. Any ideas why this fails on your machine?
> >
> > Yes, the fchdir(G.root_fd) is not enough to break the jail. (And it's not
> > just my machine. It's all of our Ubuntu versions and all of our uClinux
> > versions. Which made me assume that it was a general issue.)
> >
> > There's a nice quote, I think: Ref: http://m.oschina.net/blog/113399. (One
> > of the first hits on google. There're prolly better sources.)
> >
> > ===
> >
> >
> > /* Partially break out of the chroot jail by doing an fchdir()
> > This only partially breaks out of the chroot() jail since whilst
> > our current working directory is outside the chroot jail, our
> > root directory is still within it. Thus anything which refers to
> > "/" will refer to files under the chroot point.
> > */
> > if (fchdir(dir_fd)<0) {
> > fprintf(stderr, "Failed to fchdir - %s\n",
> > strerror(errno));
> > exit(1);
> > }
>
> The point is, we *do not* refer to "/".
> We exec "proc/self/exe", NOT "/proc/self/exe".
>
> It does work on my machine.
>
> How come it doesn't work on your machine?
If proc/self/exe make be relative to the working directory, but
/lib/ld-whatever.so from proc/self/exe's PT_INTERP header is certainly
not relative. This is the cause of the ENOENT.
Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix
On Thu, Jun 26, 2014 at 1:37 PM, Morten Kvistgaard
wrote:
>>> ...
>>> execve("proc/self/exe", ["ftpd", "-l", "/"], [/* 9 vars */]) = -1
>>> ENOENT (No such file or directory) ...
>>
>>This is strange. Any ideas why this fails on your machine?
>
> Yes, the fchdir(G.root_fd) is not enough to break the jail. (And it's not
> just my machine. It's all of our Ubuntu versions and all of our uClinux
> versions. Which made me assume that it was a general issue.)
>
> There's a nice quote, I think: Ref: http://m.oschina.net/blog/113399. (One of
> the first hits on google. There're prolly better sources.)
>
> ===
>
>
> /* Partially break out of the chroot jail by doing an fchdir()
> This only partially breaks out of the chroot() jail since whilst
> our current working directory is outside the chroot jail, our
> root directory is still within it. Thus anything which refers to
> "/" will refer to files under the chroot point.
> */
> if (fchdir(dir_fd)<0) {
> fprintf(stderr, "Failed to fchdir - %s\n",
> strerror(errno));
> exit(1);
> }
The point is, we *do not* refer to "/".
We exec "proc/self/exe", NOT "/proc/self/exe".
It does work on my machine.
How come it doesn't work on your machine?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/6] Add a unit-testing framework to Busybox
2014-06-26 14:12 GMT+02:00 Rich Felker : > On Thu, Jun 26, 2014 at 12:35:53PM +0200, Denys Vlasenko wrote: >> Global data is initialized to zero at program load time. > > And even if you need a non-zero initial value, static initialization > is usually suitable; there's no need for code for this kind of thing. > > Rich I wasn't sure of that, thanks. If we only use the INIT_LAST macro, I propose to rename it to INIT_FUNC and not use the priority argument for constructor attribute. Please see the patch in attachment. Bartosz Gołaszewski 0001-Rename-INIT_LAST-to-INIT_FUNC-to-avoid-confusion.patch Description: Binary data ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [Question] Questions about the BusyBox specification.
On Thursday 26 June 2014 14:05:34 Frank Ihle wrote: > Dear BusyBox, > > due to we consider about using BusyBox on our Embedded System, I have some > questions left whose answers couldn't be found on the BusyBox homepage or > documentation. > > I hope somebody can give me a bit more information, probably these > questions/answers could be put on the BusyBox homepage, since I think that > other developers trying to get into touch with BusyBox are interested in > these kind of information too. > > Here are the questions: > > (1) What is the minimum footprint in flash memory of BusyBox ? Footprint depends on the build: statically or dynamically linked and on the number of features and/or appletts you compile in. > (2) Is there a number for the latency to handle events (e.g. interrupt > latency) ? Don't know. > (3.1) Is there an investigation about power consumption with BusyBox during > sleep modes ? Don't know. > (3.2) Is there an investigation about power consumption with BusyBox during > normal/(full) operation mode? Don't know. > (4) Are sleep modes configurable ? Don't know. > (5) How many GPIO user out/inputs can be used e.g.: for user interaction > (buttons, LEDS, dip-switches ...) ? I think this is not related to busybox > (6) Is there a (stateless/statefull) firewall for BusyBox ? I think this is not related to busybox. Use iptables? > (7.1) Does BusyBox provide a Network stack ? Run: make menuconfig and look under Networking utilities > (7.2) Does BusyBox provide a Bluetooth stack ? Would say no. > (7.3) Does BusyBox provide a ZigBee stack ? Would say no. > (7.4) Does BusyBox provide a ZWave stack ? Would say No. > (7.5) Does Busybox provide a 6LOWPAN stack ? Wouls say no. > (8.1) Due to BusyBox seems to be written in C, is it still possible to > execute a C++ application successfully ? Yes, If your system has the relevant c++ libraries. > (8.2) Is it possible to execute a Java application ? Yes, if your system has the relevant java runtime environment. > (9) Can applications be debugged while they are executed on the target ? Yes, with strace and/or by enabling Busybox Settings -> Debugging options at compile time. > (10) What is the long-term availability of BusyBox? Can it be expected to be > available for at least 10 years ? You download the source, you will have it forever. > (11) Is remote login to a target possible, that is running with BusyBox? > (e.g. with telnet or SSH) Telnet yes. SSH only if you install a separate SSH server (e.g. Dropbear) > I apologize for questions, that may have already been answered. Thanks for > your help. > > Kind Regards > > Frank Ihle Hope this helps. Ciao, Tito ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix
> I have no idea why soneone would use NOMMU on Ubuntu, but most likely busybox > is dynamically linked and therefor exec busybox fails because it doesn't find > the dynamic linker. Even if it would find the dynamic linker, the linker > wouldn't find the dynamic libraries. Busybox is not configured to "Build shared libbusybox" if that's what you mean. The reason to use NOMMU on Ubuntu is to show that it's not working. It's much easier to test Ubuntu than a Blackfin based uClinux. -- This message has been scanned for viruses and dangerous content by CronLab (www.cronlab.com), and is believed to be clean. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/6] Add a unit-testing framework to Busybox
On Thu, Jun 26, 2014 at 12:35:53PM +0200, Denys Vlasenko wrote: > On Thu, Jun 26, 2014 at 12:00 PM, Bartosz Gołaszewski > wrote: > > 2014-06-22 16:31 GMT+02:00 Denys Vlasenko : > >> Applied all patches with some editing. > >> Thanks a lot! > > > > Hi Denys, > > > > I see, that you removed the INIT_FIRST macro from my implementation. > > Are you sure llist_t *tests will always be initialized before calling > > the test registering functions? > > Global data is initialized to zero at program load time. And even if you need a non-zero initial value, static initialization is usually suitable; there's no need for code for this kind of thing. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix
Denys Vlasenko wrote:
On Thu, Jun 26, 2014 at 11:45 AM, Morten Kvistgaard
wrote:
I've attached my strace.
I'm not sure that it tells me anything though.
I've run: sudo strace -p -f -o ftpd.strace
Is there a better way?
Anyway, the current code will exit jail with the following code:
...
if (fchdir(G.root_fd) != 0)
_exit(127);
...
But on my Ubuntu and uClinux that's not enough to break out of jail.
What do you mean? In your strace, fchdir succeeds:
15144 fchdir(3
15143 <... mmap2 resumed> ) = 0xb77d
15144 <... fchdir resumed> )= 0
And so the following code will fail:
...
/* + 1: we must use relative path here if in chroot.
* For example, execv("/proc/self/exe") will fail, since
* it looks for "/proc/self/exe" _relative to chroot!_ */
execv(bb_busybox_exec_path + 1, (char**) argv);
_exit(127);
...
The strace might reflect this:
...
execve("proc/self/exe", ["ftpd", "-l", "/"], [/* 9 vars */]) = -1 ENOENT (No
such file or directory)
...
This is strange. Any ideas why this fails on your machine?
Morten Kvistgaard wrote:
But on my Ubuntu and uClinux that's not enough to break out of jail. And so the
following code will fail:
I have no idea why soneone would use NOMMU on Ubuntu, but most likely
busybox is dynamically linked and therefor exec busybox fails because it
doesn't find the dynamic linker. Even if it would find the dynamic
linker, the linker wouldn't find the dynamic libraries.
Why does the child process only chdir and no chroot?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[Question] Questions about the BusyBox specification.
Dear BusyBox, due to we consider about using BusyBox on our Embedded System, I have some questions left whose answers couldn't be found on the BusyBox homepage or documentation. I hope somebody can give me a bit more information, probably these questions/answers could be put on the BusyBox homepage, since I think that other developers trying to get into touch with BusyBox are interested in these kind of information too. Here are the questions: (1) What is the minimum footprint in flash memory of BusyBox ? (2) Is there a number for the latency to handle events (e.g. interrupt latency) ? (3.1) Is there an investigation about power consumption with BusyBox during sleep modes ? (3.2) Is there an investigation about power consumption with BusyBox during normal/(full) operation mode? (4) Are sleep modes configurable ? (5) How many GPIO user out/inputs can be used e.g.: for user interaction (buttons, LEDS, dip-switches ...) ? (6) Is there a (stateless/statefull) firewall for BusyBox ? (7.1) Does BusyBox provide a Network stack ? (7.2) Does BusyBox provide a Bluetooth stack ? (7.3) Does BusyBox provide a ZigBee stack ? (7.4) Does BusyBox provide a ZWave stack ? (7.5) Does Busybox provide a 6LOWPAN stack ? (8.1) Due to BusyBox seems to be written in C, is it still possible to execute a C++ application successfully ? (8.2) Is it possible to execute a Java application ? (9) Can applications be debugged while they are executed on the target ? (10) What is the long-term availability of BusyBox? Can it be expected to be available for at least 10 years ? (11) Is remote login to a target possible, that is running with BusyBox? (e.g. with telnet or SSH) I apologize for questions, that may have already been answered. Thanks for your help. Kind Regards Frank Ihle ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix
>> ...
>> execve("proc/self/exe", ["ftpd", "-l", "/"], [/* 9 vars */]) = -1
>> ENOENT (No such file or directory) ...
>
>This is strange. Any ideas why this fails on your machine?
Yes, the fchdir(G.root_fd) is not enough to break the jail. (And it's not just
my machine. It's all of our Ubuntu versions and all of our uClinux versions.
Which made me assume that it was a general issue.)
There's a nice quote, I think: Ref: http://m.oschina.net/blog/113399. (One of
the first hits on google. There're prolly better sources.)
===
/* Partially break out of the chroot jail by doing an fchdir()
This only partially breaks out of the chroot() jail since whilst
our current working directory is outside the chroot jail, our
root directory is still within it. Thus anything which refers to
"/" will refer to files under the chroot point.
*/
if (fchdir(dir_fd)<0) {
fprintf(stderr, "Failed to fchdir - %s\n",
strerror(errno));
exit(1);
}
===
You still need to set the root back in place. Eg.
chroot(".");
Slightly better source perhaps: http://linux-vserver.org/Secure_chroot_Barrier
(Second hit in my google.)
--
This message has been scanned for viruses and dangerous content by CronLab
(www.cronlab.com), and is believed to be clean.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: udhcpd leases file is not written
On Tue, Jun 24, 2014 at 6:04 PM, Vinothkumar Vivekanandan wrote: > I am using BusyBox based dhcp server, udhcpd. > > This is my configuration file. But no lease details is been written in > /var/lib/misc/udhcpd.leases. Need some help. I need more data: - busybox version - .config file - "strace -oLOG -s99 -tt" of a udhcpd run ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix
On Thu, Jun 26, 2014 at 11:45 AM, Morten Kvistgaard
wrote:
> I've attached my strace.
>
> I'm not sure that it tells me anything though.
> I've run: sudo strace -p -f -o ftpd.strace
> Is there a better way?
>
> Anyway, the current code will exit jail with the following code:
>
> ...
> if (fchdir(G.root_fd) != 0)
> _exit(127);
> ...
>
> But on my Ubuntu and uClinux that's not enough to break out of jail.
What do you mean? In your strace, fchdir succeeds:
15144 fchdir(3
15143 <... mmap2 resumed> ) = 0xb77d
15144 <... fchdir resumed> )= 0
> And so the following code will fail:
>
> ...
> /* + 1: we must use relative path here if in chroot.
> * For example, execv("/proc/self/exe") will fail, since
> * it looks for "/proc/self/exe" _relative to chroot!_ */
> execv(bb_busybox_exec_path + 1, (char**) argv);
> _exit(127);
> ...
>
>
> The strace might reflect this:
> ...
> execve("proc/self/exe", ["ftpd", "-l", "/"], [/* 9 vars */]) = -1 ENOENT (No
> such file or directory)
> ...
This is strange. Any ideas why this fails on your machine?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/6] Add a unit-testing framework to Busybox
On Thu, Jun 26, 2014 at 12:00 PM, Bartosz Gołaszewski wrote: > 2014-06-22 16:31 GMT+02:00 Denys Vlasenko : >> Applied all patches with some editing. >> Thanks a lot! > > Hi Denys, > > I see, that you removed the INIT_FIRST macro from my implementation. > Are you sure llist_t *tests will always be initialized before calling > the test registering functions? Global data is initialized to zero at program load time. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/6] Add a unit-testing framework to Busybox
2014-06-22 16:31 GMT+02:00 Denys Vlasenko : > Applied all patches with some editing. > Thanks a lot! Hi Denys, I see, that you removed the INIT_FIRST macro from my implementation. Are you sure llist_t *tests will always be initialized before calling the test registering functions? Bartosz Gołaszewski ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix
On Thu, Jun 26, 2014 at 9:27 AM, Morten Kvistgaard
wrote:
> Here's how to reproduce the error:
>
> I'm using a i386 Ubuntu 10.04.
>
> - Enable the "Force NOMMU build" in menuconfig. (Also make sure the ftpd is
> added.)
> - Add the busybox ftpd to your inetd. Something like:
>
> ftp stream tcp nowait root/home/mk/workspace/busybox/busybox
> busybox ftpd -w /home/
>
> - The important part is the jail dir. Eg. "/home/". Whatever. Make sure it
> has a file or two. (And reload your inetd.)
> - Open your favorite ftp client against the server. I'm using WinSCP,
> FileZilla or win32 ftp.
> - If the ftp client can list your files, then all is good. (Mine cannot.)
Mine works. Here's what strace shows:
execve("./busybox", ["./busybox", "ftpd", "/home"], [/* 53 vars */]) = 0
...
...
read(0, "LIST\r\n", 4096) = 6
getcwd("/", 192)= 2
pipe([5, 6])= 0
vfork() = 21778
The vfork'ed child does this:
fchdir(3) = 0
close(5)= 0
dup2(6, 1) = 1
close(6)= 0
close(0)= 0
dup(1) = 0
execve("proc/self/exe", ["ftpd", "-l", "/"], [/* 46 vars */]) = 0
<--snip unimportant syscalls-->
chdir("/") = 0
<--snip unimportant syscalls-->
lstat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFIFO, st_size=3210253738927550530, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x9554000) = 0x9554000
getdents64(3, /* 35 entries */, 4096) = 1600
As you see, argv[2] of the helper is "/",
and since helper is still chroot'ed to /home,
when it executes this xchdir("/"):
if (opts & (OPT_l|OPT_1)) {
/* Our secret backdoor to ls */
xchdir(argv[2]); < HERE
argv[2] = (char*)"--";
/* memset(&G, 0, sizeof(G)); - ls_main does it */
return ls_main(argc, argv);
}
it ends up exactly in /home, and will list its files.
> The problem lies in the "exit jail" under the NO_MMU part.
Sorry.
I don't understand your bug description, you need to be more verbose.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
RE: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix
Hello Denys, Here's how to reproduce the error: I'm using a i386 Ubuntu 10.04. - Enable the "Force NOMMU build" in menuconfig. (Also make sure the ftpd is added.) - Add the busybox ftpd to your inetd. Something like: ftp stream tcp nowait root/home/mk/workspace/busybox/busybox busybox ftpd -w /home/ - The important part is the jail dir. Eg. "/home/". Whatever. Make sure it has a file or two. (And reload your inetd.) - Open your favorite ftp client against the server. I'm using WinSCP, FileZilla or win32 ftp. - If the ftp client can list your files, then all is good. (Mine cannot.) The problem lies in the "exit jail" under the NO_MMU part. Regards, Morten Kvistgaard -Original Message- From: Denys Vlasenko [mailto:vda.li...@googlemail.com] Sent: 25. juni 2014 16:23 To: Morten Kvistgaard Cc: Bernhard Reutner-Fischer; busybox@busybox.net Subject: Re: ftpd authentication [PATCH] ftpd: NOMMU/chroot fix On Tue, Jun 24, 2014 at 2:25 PM, Morten Kvistgaard wrote: > Hello Bernhard, > > The first patch for ftpd authentication is a bug fix for NOMMU platforms. > > You need a working jail in order for the authentication to make sense. (And > I've got a NOMMU platform.) The patch has been tested on both NOMMU and > normal platforms. What bug does it fix? I just tested current git and it works. (Also, your patch is whitespace damaged, please send future patches as attachments if in doubt that your mail program does not corrupt inline patches). -- This message has been scanned for viruses and dangerous content by CronLab (www.cronlab.com), and is believed to be clean. 0001-NOMMU-chroot-fix.patch Description: 0001-NOMMU-chroot-fix.patch ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
