Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> The problem is that it doesn't crash if run in gdb, but it does crash if
> not.
BTW, this is called a heisenbug. The Jargon file says about them:
"In C, nine out of ten heisenbugs result from uninitialized auto
variables, fandango on core phenomena (
On Sun, May 26, 2002 at 11:02:41PM -0400, Roland McGrath wrote:
> > I am not sure if the client side is all proper, though. The magic server
> > returned 0 nentries, data and datalen pointing to one dir entry. I have
> > forgotten how the code flow exactly was on the client side, but it seemed
>
On Sun, May 26, 2002 at 03:23:05PM +0200, Marcus Brinkmann wrote:
> I am not sure if the client side is all proper, though. The magic server
> returned 0 nentries, data and datalen pointing to one dir entry. I have
> forgotten how the code flow exactly was on the client side, but it seemed
> to
On Sun, May 26, 2002 at 03:23:05PM +0200, Marcus Brinkmann wrote:
> So, basic functionality is there, stress testing needs to be done still.
Turns out that it is still flakey. In particular, clients get mig errors
(wrong msg id in reply), and Perl modules loaded don't return 1 (this is of
course
On Sun, May 26, 2002 at 04:16:27AM +0200, Marcus Brinkmann wrote:
> $ ls /dev/fd
> Segmentation fault
Ok, this was easily fixed by correcting an off-by-one error in magic:
2002-05-26 Marcus Brinkmann <[EMAIL PROTECTED]>
* magic.c (trivfs_S_dir_readdir): Increment I after comparing it
On Fri, May 24, 2002 at 02:50:00PM -0400, Roland McGrath wrote:
> Probably the bug is in libc having to do with the /dev/fd* lookups.
> Try a test program that calls stat or lstat on all those bogus /dev/fd*
> names that appear in the make -d output.
Good instinct. After spending a bit of time i
Probably the bug is in libc having to do with the /dev/fd* lookups.
Try a test program that calls stat or lstat on all those bogus /dev/fd*
names that appear in the make -d output.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/
On Fri, May 24, 2002 at 04:43:47AM +0200, Marcus Brinkmann wrote:
> The thing that does not work is "fakeroot debian/rules target", where
> debian/rules is a makefile. It fails with:
>
> fakeauth: Segmentation fault for child NR
Who could expect that this is actually a problem in make with /dev
On Thu, May 23, 2002 at 11:36:36PM +0200, Marcus Brinkmann wrote:
> Ayup. The problem is with the access() function.
Roland's fix is ok, now those programs all work (nano, lynx, emacs...).
However, it is still not usable to build packages. In one case we made a
step back compared with the old
On Thu, May 23, 2002 at 07:50:21PM +0200, Marcus Brinkmann wrote:
> Curses applications have a problem
Ayup. The problem is with the access() function.
When you just do an access("file", R_OK), the netfs_report_access() function
has np->nn->openmodes == 0, so it says Permission denied.
Roland,
Hi,
the new fakeroot of course introduced a couple of more bugs. I fixed the
obvious ones, and now it works as good as the old one plus that suid
programs and scripts work.
However, there are a couple of other programs, but I have not made progress
so far. Curses applications have a problem, m
> Ok. For the normal case, why do we bother with the io_identity check
> at all?
To ensure correctness when noone is lying but for whatever reason the name
does not actually match (such as the race).
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http:
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Hrm, I'm beginning to wonder whether the mere fact that fakeroot can
> > fake this doesn't mean that the io_identity check isn't sufficient for
> > the security that #! execution needs...
>
> It only needs security for EXEC_SECURE, in which case a)
> Hrm, I'm beginning to wonder whether the mere fact that fakeroot can
> fake this doesn't mean that the io_identity check isn't sufficient for
> the security that #! execution needs...
It only needs security for EXEC_SECURE, in which case a) it doesn't use
that code (always /dev/fd), and b) you
Roland McGrath <[EMAIL PROTECTED]> writes:
> > But isn't this connected to the case of whether the /dev/fd method
> > works? If we make that method work, then the io_identity check isn't
> > necessary, right?
>
> The other method is still preferable.
Hrm, I'm beginning to wonder whether the me
> But isn't this connected to the case of whether the /dev/fd method
> works? If we make that method work, then the io_identity check isn't
> necessary, right?
The other method is still preferable.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://ma
Roland McGrath <[EMAIL PROTECTED]> writes:
> We have to implement
> netfs_S_dir_lookup ourselves, so that it can return partial results using
> FS_RETRY_MAGICAL to the user.
I think this is generally true for weird things like fakeroot. Back
when, this was my general intention for weird thing
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Right, but I think the same thing is true in the case of fakeroot. At
> > least, I think so unless there is some clear reason why it should face
> > io_identity.
>
> If you'd been following the discussion you'd have noticed that this came up
> in t
> Ha, that was way too easy with rpctrace. It turns out that /dev/fd/3 is
> looked up in the namespace of the fakeroot translator, which conveniently,
> but in a fundamentally broken way looks up the node and does all the MAGIC
> interpretation itself.
Duh. One of these days I will switch my br
> Right, but I think the same thing is true in the case of fakeroot. At
> least, I think so unless there is some clear reason why it should face
> io_identity.
If you'd been following the discussion you'd have noticed that this came up
in the context of #! exec's lookup of the script file name.
On Tue, May 14, 2002 at 09:06:44PM -0400, Roland McGrath wrote:
> The file_exec call on the interpreter (sh) is where it goes from there.
> That in turn results in an ordinary exec_exec of the interpreter file.
> If you're unclear on what happens after that, read exec.c:do_exec,
> S_exec_startup
Roland McGrath <[EMAIL PROTECTED]> writes:
> > It is either indistinguishable, in which case it doesn't need to
> > exist, or it has *some* difference in semantics--any difference
> > whatsoever--in which case it should not share the same identity port.
>
> You seem to be talking about some gene
> It is either indistinguishable, in which case it doesn't need to
> exist, or it has *some* difference in semantics--any difference
> whatsoever--in which case it should not share the same identity port.
You seem to be talking about some general principle of filesystem
properness. In the case o
> I don't get it. I have verified that exec correctly increases the dtable
> size from 3 to 4, and adds the file port to it. I set a breakpoint at
> S_exec_exec, and first it is hit executing "bashbug" with dtablesize 3,
> and then it is hit executing /bin/sh /dev/fd/3 with dtablesize being 4,
>
On Mon, May 13, 2002 at 05:45:21PM -0400, Roland McGrath wrote:
[me wrote]
> > However, if I don't lock the node, I get "/dev/fd/3: Bad file descriptor".
>
> Please investigate the latter problem. Firstly, (assuming non-suid
> scripts) it should find a name instead of using the /dev/fd kludge un
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Well, we are not really talking about file_chmod, but about
> netfs_attempt_chmod. However, I have not found it to be used by anything
> but netfs_S_file_chmod.
>
> The original comment is in libnetfs/netfs.h
Ok, that internal interface is used to
On Mon, May 13, 2002 at 10:54:54PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > There is another problem with fakeroot, and that is chmod. It doesn't work
> > at all :) I always get EOPNOTSUPP. Your comment:
> >
> >Unlike the normal Unix
> >a
> I'm pretty sure that fakeroot should *not* override identity--for the
> reason at least that it is *NOT* the same node.
But it's pretending to be.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Roland McGrath <[EMAIL PROTECTED]> writes:
> > I'm pretty sure that fakeroot should *not* override identity--for the
> > reason at least that it is *NOT* the same node.
>
> But it's pretending to be.
It is either indistinguishable, in which case it doesn't need to
exist, or it has *some* differ
Roland McGrath <[EMAIL PROTECTED]> writes:
> Duh. The file_exec to the underlying node calls exec_exec with a port to
> the underlying node, but the INIT_PORT_CRDIR used to start the lookup is
> the fakeroot one. We should probably override netfs_S_io_identity to lie
> and return the underlying
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> There is another problem with fakeroot, and that is chmod. It doesn't work
> at all :) I always get EOPNOTSUPP. Your comment:
>
>Unlike the normal Unix
>and Hurd meaning of chmod, this function is also used to attempt to
>change files
> ... and exec does it's own attempt at synchronization, so that it sees a
> consistent file content. Yeah, locking it was bogus. I am wondering if for
> the other calls locking is also unnecessary (although not harmful) as we are
> only passing through and the locking of the "real" node at the
On Mon, May 13, 2002 at 05:45:21PM -0400, Roland McGrath wrote:
> There is no need to lock the node and indeed it is bad to do so, as you
> see. (There is no need to lock because the file port never changes while
> the node lives.)
... and exec does it's own attempt at synchronization, so that i
> I tried the cruel way and just #if 0'ed out the whoel S_ISCHR... block (but
> not the symlink handling), and it worked fine. Which form should the hook
> take? A function that netfs_S_dir_lookup calls and that we override?
It could just be a flag global variable. Conversely, struct node coul
> Mmh, how is this done correctly? I have implemented the netfs_S_file_exec
> pass-through, which works for suid programs, but not for scripts:
> If the program is a script, the file_exec call will dead lock, because exec
> tries to lock up the file node while it is locked in netfs_S_file_exec.
On Sun, May 12, 2002 at 10:21:35PM -0400, Roland McGrath wrote:
> > Ugh, netfs_attempt_lookup did not fail, but netfs_S_dir_lookup does! This
> > is because it sees that S_ISCHR evaluates to true on the node. Because
> > fakeroot has no translator started on the node yet, fshelp_fetch_root will
On Sun, May 12, 2002 at 07:40:05PM -0400, Roland McGrath wrote:
> That makes sense. Indeed, fakeroot is netfs so it exec's by accessing the
> underlying node the same way exec'ing on nfs accesses the remote file.
> It's fshelp_exec_reauth trying the makeauth call that rightly fails since
> fakero
On Sun, May 12, 2002 at 07:40:05PM -0400, Roland McGrath wrote:
> There are a few different ways to attack this:
>
> 1. Override netfs_S_file_exec to just pass it through. Then a setuid exec
>will be a real setuid exec and will escape from the fakeroot and
>fakeauth universes entirely.
> Ugh, netfs_attempt_lookup did not fail, but netfs_S_dir_lookup does! This
> is because it sees that S_ISCHR evaluates to true on the node. Because
> fakeroot has no translator started on the node yet, fshelp_fetch_root will
> try to do so.
I see. This is just a case of not matching the assum
On Sun, May 12, 2002 at 07:40:05PM -0400, Roland McGrath wrote:
> > * Creating pipe fails also with Operation not permitted, and I have no clue
> > yet why. /servers/socket/1 is correctly looked up (with flags being 0, by
> > the way), and then I don't think the pflocal server is even involved
> Cruel. So the code in libpager/demux.c is actually wrong in using the
> remote part rather than the local port, I take it?
Yes.
> > Do you mean the issue of peropen state that I mentioned, or something else?
>
> Yeah, that one.
Ok, I don't think that will bite for the package-building uses
On Sun, May 12, 2002 at 05:14:17PM -0400, Roland McGrath wrote:
> > Cool, I started implementing it when I noticed that it isn't too easy to
> > construct the mach_msg call from the inp.
>
> Sure it is.
Well, I will reserve my final judgement for the time when everything works
as it should :)
> Well, ok. I will use my locally compiled glibc for a while, but it is
> difficult to get it tested with hardly anything using posix_spawn. So this
> is an incentive for me to compile bash, make and gcc using posix_spawn and
> give this code some testing.
Getting stuff to use posix_spawn is a
On Sun, May 12, 2002 at 03:51:09PM -0400, Roland McGrath wrote:
> Definitely not. I don't think you should use it for the debian version
> either. That code is too young. What we can do is make fakeauth use the
> underlying hurdish stuff directly instead of either fork or spawn.
Well, ok. I w
> fakeauth works with spawni.c from the glibc 2.3 (HEAD) branch. Roland, any
> plans to put this into the 2.2 branch?
Definitely not. I don't think you should use it for the debian version
either. That code is too young. What we can do is make fakeauth use the
underlying hurdish stuff directl
Hi,
I have done a few tests.
fakeauth works with spawni.c from the glibc 2.3 (HEAD) branch. Roland, any
plans to put this into the 2.2 branch? We can probably do this only for
the Debian package, too. (The reason it doesn't work right now is that
fork() creates a new receive right for the fak
46 matches
Mail list logo
