Re: firmlink deleting files on boot / interpretation of find -xdev switch

2016-09-07 Thread Brent W. Baccala 
On Wed, Sep 7, 2016 at 11:49 AM, Richard Braun  wrote:

>
> We really, really don't want to make standard Unix tools aware of
> Hurd-specific stuff, because that allows us to completely reuse the
> work of others. With a trend towards systemd, it's even more likely
> that our efforts will be put into providing some of the stuff specific
> to _others_ system instead.
>

> Personally, I would consider any solution that isn't entirely contained
> in the Hurd (kernel, servers, glibc and related) to be a no-go.
>

OK, I understand.  I personally lean in the direction of adding something
like an "-xtrans" switch to find, telling it not to enter translators,
because that's a lot clearer than usurping the interpretation of existing
switches from systems without translators.  However, I also appreciate the
wisdom in what you say, in which case I revert to my earlier suggestion of
modifying the FTS code in glibc to interpret FTS_XDEV to mean "don't enter
translators".


> > Makes sense.  The parent is where you've got all that information.  Is
> > there no way to retrieve it?
>
> There might, I haven't looked thoroughly, and it could be implemented
> if needed.
>

OK.  I just though I might be overlooking something obvious.


> We'd also have to make sure that remove()/unlink()/rmdir() don't cross
> the file system into the untrusted translator.


How do we do that without modifying programs?  Probably the FTS code;
that's what both rm and find seem to use to transverse directory structures.

Also, I agree with Kalle that not entering translators should be the
default for "rm".  If so, and we modify FTS without touching the programs,
then it also becomes the default for "chmod", "chown", "chcon", "grep", and
"du".  In particular, I don't think we want that for "grep" (not so sure
about the others).

If I understand you, Richard, you'd like to see grep's default be to enter
trusted translators, but not untrusted ones.  Am I correct?

I'm not sure I understand when you say "More limited in that our trust
> set is finite". Actually, we'd like our trust set _not_ to be finite,
> since we want the system to be extensible, by both the admin and any
> unprivileged user. Again, too rigid.


I meant that we have a standard set of trusted translators in /hurd, and
that set is finite, just like the set of programs in /bin is finite.  We
certainly don't have a means for verifying any old program in a user's bin
directory to see if it's safe to run as root.

Would you like to see a scheme where only a limited set of trusted
translators were accessible to a process, and the user had the ability to
extend the trust set of his own processes?  Something like adding
directories to your own PATH, but this would apply to translators running
under different UIDs, and not just programs that you started yourself?

agape
brent

Re: mach_msg blocking on call to vm_map

2016-09-07 Thread Brent W. Baccala 
On Thu, Sep 1, 2016 at 2:16 PM, Richard Braun  wrote:

>
> Therefore I'm going back to the idea of using a thread pool. If a
> mach_msg call succeeds, good for you, grab the next message. If not,
> at least you're not affecting other users, except maybe through a
> denial of service, the only kind of security issue inevitable with
> a design where servers allocate from their own resources on behalf
> of their clients. That's when you get to things like quotas and
> resource limits.
>

I've implemented this approach in the latest version of netmsg.  In
addition to isolating the effects of a blocking mach_msg call, this also
has the advantage of dealing (in the same way) with OOL data backed by a
faulty memory manager that causes the memory access to block indefinitely.

Of course, we really don't want our memory managers stalling indefinitely,
and, to that end, I've implemented the following, very simple, change to
libpager.  It just notifies the kernel that it can't handle a particular
memory object request, rather than remaining silent:

 --- /home/baccala/src/hurd/libpager/object-init.c2016-08-03
12:11:39.099553252 -1000
+++ object-init.c2016-09-07 12:05:24.825456046 -1000
@@ -54,6 +54,8 @@
 p->init_head = i;
   p->init_tail = i;
 #else
+  memory_object_ready (control, p->may_cache, p->copy_strategy);
+  memory_object_destroy (control, EBUSY);
   printf ("pager dup init\n");
 #endif
   goto out;

It's not perfect.  It leaks ports, since it never destroys the control and
name ports, but fixing that is not so trivial as just releasing the send
rights, because the kernel will follow up the memory_object_destroy with a
memory_object_terminate that includes the receive rights on those ports.

What this change does do, however, is expose the bug in glibc that I just
opened a bug report on.  Once that's dealt with (and the current netmsg
code deals with it), then attempting to exec a remote program using the
standard exec server doesn't hang, but instead produces a "Killed" message
along with a slew of warnings from netmsg.

I consider this progress!

agape
brent

Re: firmlink deleting files on boot / interpretation of find -xdev switch

2016-09-07 Thread Richard Braun 
On Tue, Sep 06, 2016 at 02:49:31PM -1000, Brent W. Baccala wrote:
> Consider the case with symlinks.  If "rm" transversed them, it could be a
> big problem.  Let's see... what's the option for that?... oh, there is
> none!  Isn't that interesting?  "rm" has no option to follow symlinks!
> 
> "find" does, however.  "find -L -delete" is a dangerous combination, and
> when run as root will trigger the exact same behavior that we're seeing
> with firmlinks in /tmp.
> 
> So, part of the solution is just making sure that the system scripts and
> binaries do what we want.  That "find" command used to clean /tmp should
> not recurse into translators.  It should delete the underlying nodes
> instead.

We really, really don't want to make standard Unix tools aware of
Hurd-specific stuff, because that allows us to completely reuse the
work of others. With a trend towards systemd, it's even more likely
that our efforts will be put into providing some of the stuff specific
to _others_ system instead.

Personally, I would consider any solution that isn't entirely contained
in the Hurd (kernel, servers, glibc and related) to be a no-go.

> Makes sense.  The parent is where you've got all that information.  Is
> there no way to retrieve it?

There might, I haven't looked thoroughly, and it could be implemented
if needed.

> > The solution, whatever it is, should focus only on determining whether
> > a server can be trusted or not. This should affect everything (servers,
> > (active) translators and translator records).
> 
> Yes, we need to clearly determine when a server is trusted.  Yet I think it
> has to be both more comprehensive and more limited than that.  More
> comprehensive in that we need to determine whether programs can be trusted
> as well.  More limited in that our trust set is finite.
> 
> In this case, our trust set is "ext2fs", "find", and "bootclean.sh" (plus
> shared libraries, the kernel, the shell, etc).  We trust ext2fs to notify
> us when it's handing off to a different translator.  We trust "find" to
> respect those notifications and not to cross those boundaries.  We trust
> "bootclean.sh" to clean /tmp without touching the rest of the filesystem.

How do you define "trusting programs". If it's the path to the binary,
then I disagree, it's far too rigid. If it's a process, and it can be
determined that this process has a property that tells us we can trust
it, then yes. The "more comprehensive" part would be what property,
and how to manipulate and check them.

I'm not sure I understand when you say "More limited in that our trust
set is finite". Actually, we'd like our trust set _not_ to be finite,
since we want the system to be extensible, by both the admin and any
unprivileged user. Again, too rigid.

Finally, I also disagree that we trust "ext2fs" or "find". We trust root.
When a program is started, it trusts the initial ports it receives. We
trust the root translator, and we trust what belongs to root inside of
it. What I want is to safely extend that trust to other users (root and
self should be default), and again, to other properties (like POSIX
style capabilities). And I'd like to merely avoid contact with servers
that aren't part of this trust computing base.

We'd also have to make sure that remove()/unlink()/rmdir() don't cross
the file system into the untrusted translator.

-- 
Richard Braun

[bug #49024] gnumach links with GPLv3+ material but omits GPLv3 text

2016-09-07 Thread Kalle Olavi Niemitalo 
URL:
  

 Summary: gnumach links with GPLv3+ material but omits GPLv3
text
 Project: The GNU Hurd
Submitted by: kon
Submitted on: Wed Sep  7 21:24:34 2016
Category: GNU Mach
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Reproducibility: None
  Size (loc): None
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

These files in gnumach carry notices saying that they are licensed under
GPLv3-or-later:

* i386/grub/acpi.h
* i386/grub/compiler.h
* i386/grub/cpu/io.h
* i386/grub/cpu/time.h
* i386/grub/cpu/types.h
* i386/grub/err.h
* i386/grub/misc.h
* i386/grub/mm.h
* i386/grub/symbol.h
* i386/grub/time.h
* i386/grub/types.h
* i386/i386at/acpi.c
* i386/i386at/acpihalt.c
* kern/gsync.c
* kern/gsync.h
* gitlog-to-changelog (not used during the build)

The gnumach source tree however does not include a copy of the GPLv3.

These files in gnumach carry notices saying they are dual licensed under
MPLv1.1 or GPLv2-only:

* linux/pcmcia-cs/include/pcmcia/bulkmem.h
* linux/pcmcia-cs/include/pcmcia/bus_ops.h
* linux/pcmcia-cs/include/pcmcia/ciscode.h
* linux/pcmcia-cs/include/pcmcia/cisreg.h
* linux/pcmcia-cs/include/pcmcia/cistpl.h
* linux/pcmcia-cs/include/pcmcia/cs.h
* linux/pcmcia-cs/include/pcmcia/cs_types.h
* linux/pcmcia-cs/include/pcmcia/driver_ops.h
* linux/pcmcia-cs/include/pcmcia/ds.h
* linux/pcmcia-cs/include/pcmcia/mem_op.h
* linux/pcmcia-cs/include/pcmcia/ss.h
* linux/pcmcia-cs/modules/bulkmem.c
* linux/pcmcia-cs/modules/cirrus.h
* linux/pcmcia-cs/modules/cistpl.c
* linux/pcmcia-cs/modules/cs.c
* linux/pcmcia-cs/modules/cs_internal.h
* linux/pcmcia-cs/modules/ds.c
* linux/pcmcia-cs/modules/ene.h
* linux/pcmcia-cs/modules/i82365.c
* linux/pcmcia-cs/modules/i82365.h
* linux/pcmcia-cs/modules/o2micro.h
* linux/pcmcia-cs/modules/ricoh.h
* linux/pcmcia-cs/modules/rsrc_mgr.c
* linux/pcmcia-cs/modules/smc34c90.h
* linux/pcmcia-cs/modules/ti113x.h
* linux/pcmcia-cs/modules/topic.h
* linux/pcmcia-cs/modules/vg468.h
* linux/pcmcia-cs/modules/yenta.h
* linux/pcmcia-cs/wireless/hermes.c
* linux/pcmcia-cs/wireless/orinoco.c

These files in gnumach carry notices saying they are licensed under
GPLv2-only:

* linux/src/drivers/scsi/BusLogic.c
* linux/src/drivers/scsi/BusLogic.h
* linux/src/include/net/ax25.h

As the FSF says neither GPLv2-only nor MPLv1.1 is compatible with
GPLv3-or-later, it seems there is a license conflict if these files are
actually linked in.

https://www.gnu.org/licenses/license-list.html#MPL
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

The Debian gnumach package does not seem to build the pcmcia and BusLogic
drivers.  Anyway, it is surely a bug that the GPLv3-or-later files are
included without a copy of the license.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

2016-09-07 Thread Brent Baccala 
URL:
  

 Summary: glibc - hurd_safe_{copyin, copyout, memmove, memset}
broken
 Project: The GNU Hurd
Submitted by: baccala
Submitted on: Wed 07 Sep 2016 09:02:09 PM GMT
Category: glibc
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Reproducibility: Every Time
  Size (loc): None
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

The hurd_safe_* routines currently fail to catch memory faults and instead
deliver signals which, if uncaught, terminate the faulting task.

The problem seems to lie in the interaction between the signal preemption code
in hurd/ and sysdeps/mach/hurd/i386/exc2signal.c's exception2signal():


 38 case EXC_BAD_ACCESS:
 39   switch (detail->exc_code)
 40 {
 41 case KERN_INVALID_ADDRESS:
 42 case KERN_MEMORY_FAILURE:
 43   *signo = SIGSEGV;
 44   detail->code = posix ? SEGV_MAPERR : detail->exc_subcode;
 45   break;


Notice that if the 'posix' flag is set, detail->code becomes SEGV_MAPERR
(#defined to be 1), instead of the faulting memory address, which the kernel
provides in exc_subcode.  However, the hurd_signal_preemptor structure, as it
is used in hurd/catch-signal.c (see also the macro HURD_PREEMPT_SIGNAL_P), is
used to compare detail->code to the memory range being accessed by the
hurd_safe_* routine to determine if the signal should be preempted.

The net result is that 1 (SEGV_MAPERR) is never in the memory range being
accessed, so the signal is never preempted.






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48930] crash server crashes after --core-file-name is changed with fsysopts

2016-09-07 Thread Kalle Olavi Niemitalo 
Follow-up Comment #2, bug #48930 (project hurd):

trans/hello-mt.c contains a nice example of how to use pthread_rwlock_t for
this kind of option.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #15806] hello translator: unquoted contents option

2016-09-07 Thread Kalle Olavi Niemitalo 
Follow-up Comment #3, bug #15806 (project hurd):

I believe this was not a bug, and the fix should be reverted.

In hurd/fsys.defs, the comment above fsys_get_options says the result should
be "sutiable for fsys_set_options". The hello and hello-mt translators do not
parse quotation marks in parse_opt nor in libtrivfs, so they should not add
any quotation marks in trivfs_append_args.

Instead, utils/fsysopts.c could add quotation marks and backslashes when it
displays the options.  Currently, it uses argz_stringify, which doesn't do
that.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #28511] string_t is limited to 1024 bytes

2016-09-07 Thread Kalle Olavi Niemitalo 
Follow-up Comment #1, bug #28511 (project hurd):

Removing the limit would require changing the prototypes of several public
functions declared in  of glibc.  'string_t retry_name' might
be replaced with a pointer to a buffer-descriptor structure that contains: the
address of the buffer; the size of the buffer; and a code that indicates how
the buffer was allocated (malloc, mmap, or stack), i.e. how to free it if it
is replaced with a larger one.

Then if you're going to change those functions, it might be a good idea to add
void* parameters to function pointers, like in qsort_r vs. qsort.  That would
reduce the need for nested functions, which require trampolines in an
executable stack.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #29809] creating a firmlink loop results in memory exhaustion

2016-09-07 Thread Kalle Olavi Niemitalo 
Follow-up Comment #3, bug #29809 (project hurd):

Perhaps this could be fixed by adding three parameters to the dir_lookup
routine:
* in max_total_lookups = Total number of directory lookups that may be caused
by this call.  If it needs more, then fail with ELOOP.  If the server thinks
the value of max_total_lookups is unreasonably high, then it can use a smaller
value instead.
* out total_lookups = Total number of directory lookups that the dir_lookup
call caused before succeeding.  If the caller is calling dir_lookup in a loop,
it can add total_lookups to a cumulative total and then compare the sum to its
own max_total_lookups limit.
* in max_lookup_depth = Number of recursion levels permitted during this call.
 If it needs more, then fail with ELOOP.  If the server thinks the value of
max_lookup_depth is unreasonably high, then it can use a smaller value
instead.

Then these would also have to be added to the various functions in
, and the translators would have to be changed to propagate
this infomation.  I think it would be straightforward to implement and pretty
easy to understand, and it would reliably give the desired ELOOP result.  On
the other hand, it would need changes in many source files, and it would not
prevent someone from hacking a custom translator to deliberately fake the
values, but then again such a program can flood the system with threads and
RPCs anyway.

I was also thinking about an alternative solution: implement migrating threads
and set a quota on the number of activations per thread; make RPCs fail if
they would exceed the quota. However, that scheme would let users deliberately
consume almost all of the activation quota of a thread and then call a
filesystem server, which would attempt to call a storage server and fail. It
might be difficult for the filesystem server to recover from such errors.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/