Re: [PATCH 2/3] Implement mountee startup.

[unlimitedscolobb]

Hello,

On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafbuddenha...@gmx.net wrote:
> On Wed, Nov 04, 2009 at 10:10:43PM +0200, Sergiu Ivanov wrote:
> > On Thu, Oct 29, 2009 at 06:37:54AM +0100, olafbuddenha...@gmx.net
> > wrote:
>
> > > Well, I can't really give a final ACK without seeing the whole patch
> > > in its final form...
> > 
> > I'm sending the current version of the patch in this mail.
> 
> Actually, it's not useful *this* time, as we are still discussing some
> of the comments, and you haven't updated them yet -- so it can't be the
> final version anyways :-)
> 
> Perhaps you didn't expect the previous version to be final either -- if
> this is the case, please pretend I never said anything about this ;-)

Well, I didn't expect the previous version to be final :-) But that's
not a problem :-) I wonder, whether this version is final, though?..
 
> > > "most RPCs ont this node can be automatically carried out correctly"
> > > is way too vague... It's not ever clear what "correct" means in
> > > here, no what RPCs you mean.
> > > 
> > > I think you should say that the mountee is set on a (clone of) the
> > > unionfs root node, so that unionfs appears as the parent translator
> > > of the mountee. AIUI that's the idea behind it, right?
[...]
> > Do you want to say that the goal of setting the mountee on a clone of
> > the root node is to make unionfs appear as the underlying translator
> > to the mountee?
[...]
> Exactly.

OK.  I've changed the comment accordingly.  Namely, the sentence now
looks like this: ``This node is based on the netnode of the root node
(it is essentially a clone of the root node), because in this way
unionfs appears as the underlying translator to the mountee.''

> I didn't want to use the term "underlying", because in the context of
> unionmount, we always used it for the underlying filesystem of the
> unionfs node; which, in the non-transparent case, is not the same as the
> underlying filesystem of the mountee... But feel free to use this term,
> if you think it causes less confusion than introducing completely new
> ones :-)

I think we should adopt some conventions in order to remove the
ambiguity of the word ``underlying''.  I'd suggest using ``underlying
translator'' to specify the order of translators in a stack,
``underlying filesystem'' for the real underlying filesystem, and
``unioned directory'' for one of the components of the union managed
by unionfs.

I'm strongly inclined to consider the term ``underlying filesystem''
used for a unioned directory to be unwieldy chosen: firstly, unionfs
is not operating on filesystems, and secondly, the directories it
operates on are not underlying to it.
 
> > I'm not sure whether this is a feature or a misbehaviour
> 
> I don't think it's a bug -- doesn't seem very likely that nobody would
> have noticed such a fundamental bug all this time...

Yeah, that's my opinion, too.
 
> But feel free to investigate this further, reading some relevant POSIX
> man-pages, and/or the server code implementing file creation. Or perhaps
> it would be easiest to try reproducing it with standard POSIX functions,
> both on Hurd and on Linux...

Yes, this is what I considered doing, but haven't yet found the time.

Regards,
scolobb

Re: Adding entries to a directory

[Sergiu Ivanov]

Hello,

On Mon, Nov 09, 2009 at 02:58:12PM +0100, Carl Fredrik Hammar wrote:
> On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafbuddenha...@gmx.net wrote:
> > 
> > > Well, obviously, O_READ permission on a directory is sufficient to
> > > create files in it.
> > 
> > Ah, interesting...
> > 
> > > I'm not sure whether this is a feature or a misbehaviour
> > 
> > I don't think it's a bug -- doesn't seem very likely that nobody would
> > have noticed such a fundamental bug all this time...
> 
> I was about to say it's definitaly a bug, but a quick look in open(2)
> states that open() should fail with EISDIR if open mode is write...
> This suggests that adding entries depend on the permission bits
> of the directory and the users and grougs of the client.

Thank you for the investigation! :-) It didn't occur to me to look
into manpages first :-(
 
> How to properly verify whether a client has this access in
> a proxy such as unionfs is an interesting question.
> If run by root it could recreate whatever auth object
> the client is using, but its harder for a normal user.

Generally, unionfs checks permissions whenever it is asked to carry
out some operation.  Similarly, when it is asked to create a new entry
under a directory, it first checks the user's permissions.

Although I fail to realize how unionfs would help root to recreate any
auth object used by a client, I'd believe that root could recreate any
auth object without the aid of unionfs, too :-)

Regards,
scolobb

[PATCH 3/3] Add the mountee to the list of merged filesystems.

[Sergiu Ivanov]

* mount.c (start_mountee): Add the mountee's filesystem to the
list of merged filesystems.
* node.c (node_init_root): Take into consideration the fact that
an empty string refers to the mountee root.
* ulfs.c (ulfs_check): Likewise.
(ulfs_register): Don't check whether "" is a valid directory.
---

Hello,

On Thu, Nov 05, 2009 at 12:58:02PM +0100, olafbuddenha...@gmx.net wrote:
> On Wed, Nov 04, 2009 at 07:08:45PM +0200, Sergiu Ivanov wrote:
> > On Fri, Oct 30, 2009 at 10:13:09AM +0100, olafbuddenha...@gmx.net
> > wrote:
> > > On Mon, Aug 17, 2009 at 08:55:37PM +0300, Sergiu Ivanov wrote:
> 
> > > > I've added the corresponding comment to ulfs_register, but I
> > > > didn't add anything to variable or structure declarations, because
> > > > I'm not sure whether it would be suitable to describe the
> > > > convention in the comment to the declaration of struct ulfs or in
> > > > the comment to the declaration of ulfs_chain.
> > > 
> > > The latter I'd say -- it's not really a property of the ulfs
> > > structure itself, but rather a special entry in the list...
> 
> Whoops, sorry, I wasn't paying attention :-(
> 
> After looking at the patch, it immediately became clear that indeed the
> comment belongs in the ulfs structure itself, not the chain -- it
> describes a special value of a particular field in the structure, while
> the chain only links the structures.

OK :-) I've moved the corresponding comment to the declaration of the
structure.
 
> > I have eventually commented both the data structures and the
> > functions, which, I hope, is not a problem :-)
> 
> Only in the sense that more redundancy means more things to update if
> something should change there... But I'm not too worried about that :-)

Neither am I :-)

Regards,
scolobb

---
 mount.c |   14 +-
 mount.h |4 +++-
 node.c  |   15 ---
 ulfs.c  |   19 +++
 ulfs.h  |8 ++--
 5 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/mount.c b/mount.c
index 01d9ccd..7da6822 100644
--- a/mount.c
+++ b/mount.c
@@ -27,6 +27,7 @@
 
 #include "mount.h"
 #include "lib.h"
+#include "ulfs.h"
 
 /* The command line for starting the mountee.  */
 char * mountee_argz;
@@ -142,7 +143,9 @@ start_mountee (node_t * np, char * argz, size_t argz_len, 
mach_port_t * port)
   return err;
 }  /* start_mountee */
 
-/* Sets up a proxy node and sets the translator on it.  */
+/* Sets up a proxy node, sets the translator on it, and registers the
+   filesystem published by the translator in the list of merged
+   filesystems.  */
 error_t
 setup_unionmount (void)
 {
@@ -164,6 +167,15 @@ setup_unionmount (void)
   if (err)
 return err;
 
+  /* A path equal to "" will mean that the current ULFS entry is the
+ mountee port.  */
+  ulfs_register ("", 0, 0);
+
+  /* Reinitialize the list of merged filesystems to take into account
+ the newly added mountee's filesystem.  */
+  ulfs_check ();
+  node_init_root (netfs_root_node);
+
   mountee_started = 1;
 
   return 0;
diff --git a/mount.h b/mount.h
index fd265f0..fb5758d 100644
--- a/mount.h
+++ b/mount.h
@@ -42,7 +42,9 @@ extern int mountee_started;
 error_t
 start_mountee (node_t * np, char * argz, size_t argz_len, mach_port_t * port);
 
-/* Sets up a proxy node and sets the translator on it.  */
+/* Sets up a proxy node, sets the translator on it, and registers the
+   filesystem published by the translator in the list of merged
+   filesystems.  */
 error_t
 setup_unionmount (void);
 
diff --git a/node.c b/node.c
index cf9a8b4..f8ad886 100644
--- a/node.c
+++ b/node.c
@@ -1,7 +1,10 @@
 /* Hurd unionfs
-   Copyright (C) 2001, 2002, 2005 Free Software Foundation, Inc.
+   Copyright (C) 2001, 2002, 2005, 2009 Free Software Foundation, Inc.
+
Written by Moritz Schulte .
 
+   Adapted for unionmount by Sergiu Ivanov .
+
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
@@ -33,6 +36,7 @@
 #include "node.h"
 #include "ulfs.h"
 #include "lib.h"
+#include "mount.h"
 
 /* Declarations for functions only used in this file.  */
 
@@ -535,8 +539,13 @@ node_init_root (node_t *node)
  break;
 
   if (ulfs->path)
-   node_ulfs->port = file_name_lookup (ulfs->path,
-   O_READ | O_DIRECTORY, 0);
+   {
+ if (!ulfs->path[0])
+   node_ulfs->port = mountee_root;
+ else
+   node_ulfs->port = file_name_lookup (ulfs->path,
+   O_READ | O_DIRECTORY, 0);
+   }
   else
node_ulfs->port = underlying_node;
  
diff --git a/ulfs.c b/ulfs.c
index 3c565a5..2626a90 100644
--- a/ulfs.c
+++ b/ulfs.c
@@ -1,7 +1,10 @@
 /* Hurd unionfs
-   Copyright (C) 2001, 2002, 2005 Free Software Foundation, Inc.
+   Copyright (C) 2001, 2002, 2005, 2009 Free Softwa

[PATCH] Implement the sync libnetfs stubs.

[Sergiu Ivanov]

* netfs.c (netfs_attempt_sync): Sync every directory associated
with the supplied node.
(netfs_attempt_syncfs): Send file_syncfs to every directory
maintained by unionfs.
---

Hello,

On Fri, Nov 06, 2009 at 09:58:31AM +0100, olafbuddenha...@gmx.net wrote:
> On Wed, Nov 04, 2009 at 06:56:41PM +0200, Sergiu Ivanov wrote:
> > On Mon, Oct 26, 2009 at 01:03:29AM +0100, olafbuddenha...@gmx.net
> > wrote:
> 
> > > I think the initialization of "i" should be as close to the loop as
> > > possible -- after all, it's a loop counter...
> > 
> > I moved it closer to the loop itself, but I didn't move it further
> > than locking the mutex, because locking the mutex is also a part of
> > initialization, and I am somehow inclined to keep variable definitions
> > before operations (but this is subjective).
> 
> Yes, I also think definitions should go before statements; I said so
> myself in some earlier mail...
> 
> However, I didn't mean moving the *definition*, but the *initialization*
> -- quite a different thing :-)

Ah, sorry :-( I didn't pay attention to this.  I've left the
definition of the variable where it was in the latest version of the
patch and put the initialization immediately before the loop.
 
> Not sure though whether it makes sense to move it inside the mutex
> lock... I see advantages to both variants. However, it might make sense
> to move the comment for the loop above the initialization and/or the
> mutex. (Again, I'm not sure... Just an idea.)

It somehow feels more natural to me to initialize the variable
immediately before the loop.  It is probably due to the standard for
(*i = 0*; ...) :-)
 
> > > Not sure whether I asked this before: is there actually any reason
> > > not to attempt syncing filesystems without FLAG_ULFS_WRITABLE as
> > > well?...
> > > 
> > > (I don't know how file_sync() or file_syncfs() bahave on filesystems
> > > or nodes that really are not writable -- but IIRC that's not what
> > > FLAG_ULFS_WRITABLE conveys anyways?...)
> > 
> > A quick search didn't reveal any indications about whether these RPCs
> > should fail on a really read-only filesystem, so, technically, syncing
> > such filesystems should not be a problem.
[...]
> > That's why I think I agree with you and I made unionfs sync every
> > unioned directory.
> 
> Well, did you actually test how it behaves with really readonly
> filesystems? (Most notably that it doesn't return an error status?)

As an example of a readonly filesystem I took xmlfs and took a glance
at it's implementation of netfs sync stubs.  And then it flashed in my
mind that all implementations of sync stubs that I've seen and which
did nothing returned 0.  I can't remember this being specified as a
convention somewhere, though.

Regards,
scolobb

---
 netfs.c |   80 --
 1 files changed, 77 insertions(+), 3 deletions(-)

diff --git a/netfs.c b/netfs.c
index 89d1bf6..3988cc7 100644
--- a/netfs.c
+++ b/netfs.c
@@ -1,5 +1,6 @@
 /* Hurd unionfs
-   Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
+   Copyright (C) 2001, 2002, 2003, 2005, 2009 Free Software Foundation, Inc.
+
Written by Moritz Schulte .
 
This program is free software; you can redistribute it and/or
@@ -282,7 +283,45 @@ error_t
 netfs_attempt_sync (struct iouser *cred, struct node *np,
int wait)
 {
-  return EOPNOTSUPP;
+  /* The error we are going to report back (last failure wins).  */
+  error_t final_err = 0;
+
+  /* The information about the currently analyzed filesystem.  */
+  ulfs_t * ulfs;
+
+  /* The index of the currently analyzed filesystem.  */
+  int i;
+
+  mutex_lock (&ulfs_lock);
+
+  /* Sync every directory associated with `np`.
+
+ TODO: Rewrite this after having modified ulfs.c and node.c to
+ store the paths and ports to the underlying directories in one
+ place, because now iterating over both lists looks ugly.  */
+  i = 0;
+  node_ulfs_iterate_unlocked (np)
+  {
+error_t err;
+
+/* Get the information about the current filesystem.  */
+err = ulfs_get_num (i, &ulfs);
+assert (!err);
+
+/* Since `np` may not necessarily be present in every underlying
+   directory, having a null port is perfectly valid.  */
+if (node_ulfs->port != MACH_PORT_NULL)
+  {
+   err = file_sync (node_ulfs->port, wait, 0);
+   if (err)
+ final_err = err;
+  }
+
+++i;
+  }
+
+  mutex_unlock (&ulfs_lock);
+  return final_err;
 }
 
 /* This should sync the entire remote filesystem.  If WAIT is set,
@@ -290,7 +329,42 @@ netfs_attempt_sync (struct iouser *cred, struct node *np,
 error_t
 netfs_attempt_syncfs (struct iouser *cred, int wait)
 {
-  return 0;
+  /* The error we are going to report back (last failure wins).  */
+  error_t final_err = 0;
+
+  /* The index of the currently analyzed filesystem.  */
+  int i = 0;
+
+  /* The information about the currently analyzed filesystem.  */
+  ulfs_t * ulfs;
+
+  mutex_loc

Re: Adding entries to a directory

[Carl Fredrik Hammar]

Hi,

On Tue, Nov 17, 2009 at 11:57:46AM +0200, Sergiu Ivanov wrote:
> On Mon, Nov 09, 2009 at 02:58:12PM +0100, Carl Fredrik Hammar wrote:
> > On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafbuddenha...@gmx.net wrote:
> > > 
> > > > Well, obviously, O_READ permission on a directory is sufficient to
> > > > create files in it.
> > > 
> > > Ah, interesting...
> > > 
> > > > I'm not sure whether this is a feature or a misbehaviour
> > > 
> > > I don't think it's a bug -- doesn't seem very likely that nobody would
> > > have noticed such a fundamental bug all this time...
> > 
> > I was about to say it's definitaly a bug, but a quick look in open(2)
> > states that open() should fail with EISDIR if open mode is write...
> > This suggests that adding entries depend on the permission bits
> > of the directory and the users and grougs of the client.
> 
> Thank you for the investigation! :-) It didn't occur to me to look
> into manpages first :-(

No biggie, it was buried deep inside the man-page.  It was pure chance
that I noticed it at all.

> > How to properly verify whether a client has this access in
> > a proxy such as unionfs is an interesting question.
> > If run by root it could recreate whatever auth object
> > the client is using, but its harder for a normal user.
> 
> Generally, unionfs checks permissions whenever it is asked to carry
> out some operation.  Similarly, when it is asked to create a new entry
> under a directory, it first checks the user's permissions.

Ah, yes.  That's what I thought.  Perhaps I should've explained what I
meant by ``properly'', which I left out in this little side note.

The problem with relying on file permissions is that it is only one
of several possible ways to specify permissions.  For instance, ACLs
(Access Control List) can offer a more fine grained control, where
permissions can be specified for individual users.

Now only regular file permissions are currently implemented by filesystems
in the Hurd, but it would be nice to have the possibility to implement
such alternatives in the future.  To ensure this we shouldn't rely on
file permissions being correct.

(But I might be missing something, perhaps POSIX says that regular file
permissions should always be correct or something.)

> Although I fail to realize how unionfs would help root to recreate any
> auth object used by a client, I'd believe that root could recreate any
> auth object without the aid of unionfs, too :-)

My idea was that a unionfs *run* by root can recreate any auth object
that the client has and then authenticate with it against the unioned
directories.

If run by any other user then it can only recreate the intersection of
credentials between unionfs and the client.  This isn't ideal, but it
does ensure that unionfs doesn't accidentally grant the client any new
permissions by mistake.

But just to clarify, I don't really propose that you implement this in
unionfs.  I think this would affect other filesystems as well; switching
over the Hurd to such a policy should be treated as a separate project.

Regards,
  Fredrik

Re: website: background color in css

[Michal Suchanek]

2009/11/17 Arne Babenhauserheide :
> Am Montag, 16. November 2009 23:07:33 schrieb Michal Suchanek:
>> It's not all or none. You can use different text style and size,
>> alignment, spacing, borders, ... and colors.
>>
>> But whenever you touch an aspect of the site, be it colors, text
>> style, or anything else you must ensure that it works as intended with
>> various reasonable defaults. This is not limited to colors.
>
> The *reasonable* is the key: You can define everything, but you can also try 
> to
> make your site adjust to the user-style as much as possible without losing
> "identity".
>
> Take the example of margins: If you add a little margin for list elements, so
> they have a bit higher spacing, and you want to make it perfect, you have to
> explicitely set the margin for every single html element you use - including
>  and similar.

It depends on the level of perfection you want to achieve.

If you simply want to add more margin because the list elements seem
easier to read that way you can just add it and be done with it. If
you want to ensure that the margin for list elements is 2x the margin
of a normal paragraph then you have to set all margins.

Similarly, if you want to put a single warning sign somewhere in
yellow on red then you just add it. If you want your site to have some
particular text color you better ensure that you define a background
on which the text is visible.

There are no defaults defined, and any default that makes unstyled
pages usable is reasonable but it cannot work wit each and every
partial style that authors of broken sites might come up with.

>
> In a language written for being used that way, you'd likel yhave a margins
> element which includes all elements which have a margin by default (or rather
> all elements which can have a margin). Whenever you wanted to change one
> element, you'd then copy the whole margin element into your custom file and
> adjust the defaults where needed.
>
> The same goes for color elements: You'd have a color config file with all the
> defaults in it. That way when you'd set one color, you'd auomatically also
> define the defaults for every element on your page.
>
> But in css you define only what you want different from the default.

Yes, if you want to write a theme you usually start by coping a
working theme and only change the things you want to change.

You could omit something in the theme and it would possibly inherit
from the default or previous theme or have some parts visibly broken
depending on the theme engine in question.

There is nothing stopping you from doing the same with CSS except
perhaps there aren't many free CSS styles available for people to
customize.

This is in part because the CSS authors may be more possessive of
their creations as they think of the style as part of their perfected
web site and in part because you need a style tailored to your site.

>
>> And best of all, neither the colors nor the font will be visible in
>> most text-only browsers.
>
> :)
>
>> > That even goes for "when you use a picture you have to define all
>> > colors".
>>
>> And how do you make a picture without defining all colors?
>
> You define an image which goes well with most settings.

Yes, there there are small b&w pixel art icons for arrows or the like
which have every feature drawn with strong black line and white
outline (or the other way around) which stand out clearly on any
background. Most other images suffer on some backgrounds, though.

>
> No (static) image will ever go well with every color, but they are elements
> you can't get rid off by using a custom style sheet, because they are often
> site-content.

When the images are site content you should put them on a background
which goes well with the images.

After all, the person should be on the page only if they look for the
images and then they can't really choose what the site would look
like, the images will take most are either way.

>
> (and it gets even worse, because not all browsers and not all *monitors*
> interpret css colors exactly the same way - sites can look vastly different on
> a Mac and a GNU/Linux machine)
>
>> The ultimate here are SVG pictures that can be styled with CSS to
>> match your site style completely but few browsers support them well at
>> this time.
>
> That sounds great!
>
> I hope I'll see them become standard!

It is a W3C standard but there is a difference between a W3C standard
and a de-facto standard supported at least by a few major browsers.

>
>> > It's prefectionism which makes life harder for everyone who writes a
>> > website.
>>
>> Yes, as I said, making things correctly might seem too extreme to some.
>
> It depends on what the effects of doing it correctly are.
>
> HTML grew mostly organically with some cancer in it (IE), so as I said, the
> "correct" way can stifle quite a few options.
>
>> Unfortunately, most web authors want to set off their web site by
>> choosing their own color theme for it.
>
> IIRC most de

Re: website: background color in css

[Arne Babenhauserheide]

Am Dienstag, 17. November 2009 14:32:29 schrieb Michal Suchanek:
> Similarly, if you want to put a single warning sign somewhere in
> yellow on red then you just add it. If you want your site to have some
> particular text color you better ensure that you define a background
> on which the text is visible.

But with warnings the same happens as with the text: They are invisble on some 
backgrounds. 

I agree though, that the effect with the main content is stronger :) 

> Yes, if you want to write a theme you usually start by coping a
> working theme and only change the things you want to change.

I don't - I learned HTML and CSS from the ground up - working directly with 
pencil and paper for the draft and then coding it by hand. 

> > IIRC most default Drupal pages do it by your standard. Example:
> > http://1w6.org
> 
> Note that this site is also broken: it has button text set but does
> not set button color.
> Buttons are colored by the system colors automatically by many
> browsers so this is bound to break.

Damn... that one is a default style with only slight changes to the 
colorscheme - done directly in an integrated config menu, so I can't easily fix 
that. 

> > "Disharmonizes" defined by "is in the table as really not working
> > together with the background".
> 
> Even detecting the situation when an element has colors which
> originate from different styles would probably need non-trivial
> support in the HTML rendering engine.

When I think about how hard it is for the Firefox people to fix the "I can read 
your browser history with a simple css trick" bug (because they do some really 
complex stuff internally), I don't think the complexity of that would be high 
compared with what they already do. 

> > I did some experimentation and brightened up the color. The site should
> > be a bit nicer to read for people with dark green background now:
> > - http://draketo.de/licht-lumo-light
> 
> I don't see much difference. I don't find the site particularly
> pleasing or easy to read as most sites designed for different colors
> don't with my background.

It won't ever be pleasing (you can hardly make red text on green pleasing - 
these two bite each other when they get too close). But from my comparision it 
is now much more readable - my eyes no longer hurt after a few seconds. 

Still, if I were you and wanted to read the site, I'd enforce my private color 
scheme :) 

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: website: background color in css

[Michal Suchanek]

2009/11/17 Arne Babenhauserheide :
> Am Dienstag, 17. November 2009 14:32:29 schrieb Michal Suchanek:
>> Similarly, if you want to put a single warning sign somewhere in
>> yellow on red then you just add it. If you want your site to have some
>> particular text color you better ensure that you define a background
>> on which the text is visible.
>
> But with warnings the same happens as with the text: They are invisble on some
> backgrounds.

They aren't because the warning has both background and text color set
but they may not be as distinguished on some backgrounds.

>
> I agree though, that the effect with the main content is stronger :)
>
>> Yes, if you want to write a theme you usually start by coping a
>> working theme and only change the things you want to change.
>
> I don't - I learned HTML and CSS from the ground up - working directly with
> pencil and paper for the draft and then coding it by hand.

Yes, with HTML you typically don't have a working site to start from,
unlike KDE theme authors you have to start from scratch. That's
probably why many people are surprised that a site that works for them
breaks in another browser.


>> > "Disharmonizes" defined by "is in the table as really not working
>> > together with the background".
>>
>> Even detecting the situation when an element has colors which
>> originate from different styles would probably need non-trivial
>> support in the HTML rendering engine.
>
> When I think about how hard it is for the Firefox people to fix the "I can 
> read
> your browser history with a simple css trick" bug (because they do some really
> complex stuff internally), I don't think the complexity of that would be high
> compared with what they already do.

You are wrong on this one. Exactly because the current rendering
engine is complex making even simple changes to it has unpredictable
results. That's why fixing anything on it takes ages.

Thanks

Michal

Re: Adding entries to a directory

[Sergiu Ivanov]

Hello,

On Tue, Nov 17, 2009 at 01:15:59PM +0100, Carl Fredrik Hammar wrote:
> On Tue, Nov 17, 2009 at 11:57:46AM +0200, Sergiu Ivanov wrote:
> > On Mon, Nov 09, 2009 at 02:58:12PM +0100, Carl Fredrik Hammar wrote:
> > > On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafbuddenha...@gmx.net wrote:
> > > > 
> > > > > Well, obviously, O_READ permission on a directory is sufficient to
> > > > > create files in it.
> 
> > > How to properly verify whether a client has this access in
> > > a proxy such as unionfs is an interesting question.
> > > If run by root it could recreate whatever auth object
> > > the client is using, but its harder for a normal user.
> > 
> > Generally, unionfs checks permissions whenever it is asked to carry
> > out some operation.  Similarly, when it is asked to create a new entry
> > under a directory, it first checks the user's permissions.
> 
> Ah, yes.  That's what I thought.  Perhaps I should've explained what I
> meant by ``properly'', which I left out in this little side note.
> 
> The problem with relying on file permissions is that it is only one
> of several possible ways to specify permissions.  For instance, ACLs
> (Access Control List) can offer a more fine grained control, where
> permissions can be specified for individual users.
> 
> Now only regular file permissions are currently implemented by filesystems
> in the Hurd, but it would be nice to have the possibility to implement
> such alternatives in the future.  To ensure this we shouldn't rely on
> file permissions being correct.

I see.  However, if I understand you correctly, you are talking about
a totally different implementation of filesystem authentication
mechanism.  In case such mechanism is ever implemented, I believe that
the permissions check in unionfs can be pretty easily adapted to the
new way: unionfs relies heavily on libfshelp, and the corresponding
permission check functions could be modified to work differently.
 
> (But I might be missing something, perhaps POSIX says that regular file
> permissions should always be correct or something.)

Hm, why could POSIX say that regular file permissions may *not* be
correct? :-) I may be missing something, but it's hard for me to
imagine that POSIX file permissions were introduced with the thought
in mind that they may be wrong.
 
> > Although I fail to realize how unionfs would help root to recreate any
> > auth object used by a client, I'd believe that root could recreate any
> > auth object without the aid of unionfs, too :-)
> 
> My idea was that a unionfs *run* by root can recreate any auth object
> that the client has and then authenticate with it against the unioned
> directories.
> 
> If run by any other user then it can only recreate the intersection of
> credentials between unionfs and the client.  This isn't ideal, but it
> does ensure that unionfs doesn't accidentally grant the client any new
> permissions by mistake.

>From the theoretical point of view, there isn't really a problem,
since unionfs should always grant permissions which are intersection
between its permissions and the permissions of the calling client.
Even if unionfs is running as root, it shouldn't give the calling
client more permissions than they already have.  OTOH, bugs can bring
about security problems in any case :-)
 
> But just to clarify, I don't really propose that you implement this in
> unionfs.  I think this would affect other filesystems as well; switching
> over the Hurd to such a policy should be treated as a separate project.

Yeah, this is clear :-) Indeed, modifying the security policy will
involve a lot of modifications to all Hurd components.

Regards,
scolobb

Re: website: background color in css

[olafBuddenhagen]

Hi,

On Sun, Nov 15, 2009 at 10:58:44AM +0100, Arne Babenhauserheide wrote:
> Am Sonntag, 15. November 2009 01:42:19 schrieb
> olafbuddenha...@gmx.net:

> > (Not everyone likes reading text on a white background! It
> > regularily makes my eyes hurt. I wonder what morons created the myth
> > that it would be more ergonomic :-( )

> The problem is, that we can't easily avoid the black font color

No idea what you mean. If a user sets his default background color, we
can safely assume that he also sets a matching default text color...

Admittedly, the Hurd site is somewhat broken in that in a few places it
overrides background color without also overriding text color. (But
never the other way round from what I've seen!)

-antrik-

Re: OT: automation

[olafBuddenhagen]

Hi,

On Sun, Nov 15, 2009 at 10:53:18AM +0100, Arne Babenhauserheide wrote:
> Am Samstag, 14. November 2009 23:57:07 schrieb
> olafbuddenha...@gmx.net:

> > > How can you best reach that goal?
> > 
> > What goal exactly?...
> 
> Having a gui and a cli interface to every command. 

Still not sure what you want to know. Are you asking for a technical
design description? For a roadmap? Or yet something else?...

-antrik-

Re: website: background color in css

[olafBuddenhagen]

Hi,

On Sun, Nov 15, 2009 at 11:17:59PM +0100, Arne Babenhauserheide wrote:
> Am Sonntag, 15. November 2009 19:44:57 schrieb Michal Suchanek:

> > So you can either have completely colorless pages 
> 
> ...and lose the wide range of options you have when you use colors for
> different parts of the text. Since people began using different colors
> for titles, the web looks far more friendly to me. 

"Completely colorless" is probably confusing. It's actually perfectly OK
to override text colors for emphasis in specific bits of text -- if you
also override the background color *for these same bits of text*. The
rest of the page can keep default colors for both text and background.

Too bad that hardly any web author sticks to this simple rule.

-antrik-

cthreads vs. pthreads (was: GNU/Hurd in german news)

[olafBuddenhagen]

hi,

On Mon, Nov 16, 2009 at 12:57:32AM +0800, Da Zheng wrote:
> Samuel Thibault wrote:
> > Da Zheng, le Sun 15 Nov 2009 12:05:01 +0800, a écrit :

> >> I thought GNOME or KDE couldn't work because Hurd components or
> >> libraries were still using cthreads instead of pthreads.
> > 
> > I don't see why.  Could you find a post explaining that?

> No, I just heard that GNOME and KDE use pthreads but Hurd components
> use cthreads. Or maybe it's just my misunderstanding. If GNOME or KDE
> uses some Hurd libraries which use cthreads, then it should be a
> problem.

There used to be a time when the Hurd didn't have pthreads at all -- but
this changed many years ago with Neal's pthreads implementation.

The remaining problem is that the Hurd translators and server libraries
still use ctreads, and thus programs linking these can't use pthreads.
But that doesn't apply to "normal" programs -- these just link the
client-side library (libc), which doesn't use cthreads.

-antrik-

Re: OT: automation

[olafBuddenhagen]

Hi,

On Sun, Nov 15, 2009 at 10:51:29AM +0100, Arne Babenhauserheide wrote:

> How about a server which exposes dbus interfaces via the filesystem to
> give instant benefit for dbus-enabled programs? 
> 
> Would that be doable? 

Yeah, I guess so...

-antrik-

Re: Adding entries to a directory

[Carl Fredrik Hammar]

Hi,

On Tue, Nov 17, 2009 at 06:49:24PM +0200, Sergiu Ivanov wrote:
> On Tue, Nov 17, 2009 at 01:15:59PM +0100, Carl Fredrik Hammar wrote:
> > On Tue, Nov 17, 2009 at 11:57:46AM +0200, Sergiu Ivanov wrote:
> > > On Mon, Nov 09, 2009 at 02:58:12PM +0100, Carl Fredrik Hammar wrote:
> > > > On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafbuddenha...@gmx.net wrote:
> > > > > 
> > > > > > Well, obviously, O_READ permission on a directory is sufficient to
> > > > > > create files in it.
> > 
> > > > How to properly verify whether a client has this access in
> > > > a proxy such as unionfs is an interesting question.
> > > > If run by root it could recreate whatever auth object
> > > > the client is using, but its harder for a normal user.
> > > 
> > > Generally, unionfs checks permissions whenever it is asked to carry
> > > out some operation.  Similarly, when it is asked to create a new entry
> > > under a directory, it first checks the user's permissions.
> > 
> > Ah, yes.  That's what I thought.  Perhaps I should've explained what I
> > meant by ``properly'', which I left out in this little side note.
> > 
> > The problem with relying on file permissions is that it is only one
> > of several possible ways to specify permissions.  For instance, ACLs
> > (Access Control List) can offer a more fine grained control, where
> > permissions can be specified for individual users.
> > 
> > Now only regular file permissions are currently implemented by filesystems
> > in the Hurd, but it would be nice to have the possibility to implement
> > such alternatives in the future.  To ensure this we shouldn't rely on
> > file permissions being correct.
> 
> I see.  However, if I understand you correctly, you are talking about
> a totally different implementation of filesystem authentication
> mechanism.  In case such mechanism is ever implemented, I believe that
> the permissions check in unionfs can be pretty easily adapted to the
> new way: unionfs relies heavily on libfshelp, and the corresponding
> permission check functions could be modified to work differently.

No, I think you're confusing authentication and access control.
Authentication is the method used to establish the identity of a client,
i.e. which user(s) and groups it is run by.  Access control is deciding
which permissions the client has, typically based on which identity
it has.

Authentication must be the same throughout the system to be useful.
Access control is all up to the individual servers, and can be different
throughout the system.  It is easy to imagine new types of access control,
e.g. owner permissions for several users, or even a time lock that denies
access after a certain date.  There are many possibilities which I think
we should leave open.

> > (But I might be missing something, perhaps POSIX says that regular file
> > permissions should always be correct or something.)
> 
> Hm, why could POSIX say that regular file permissions may *not* be
> correct? :-) I may be missing something, but it's hard for me to
> imagine that POSIX file permissions were introduced with the thought
> in mind that they may be wrong.

``Correct'' wasn't really the right word, ``incomplete'' is more
appropriate.  It seems that file permissions bits must always be present
in some form, but that additional file access permissions may further
restrict permissions:

http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_04

If this is the case then unionfs may inadvertently grant a permission
that the unioned directory would've denied due to such an additional mechanism.

> > > Although I fail to realize how unionfs would help root to recreate any
> > > auth object used by a client, I'd believe that root could recreate any
> > > auth object without the aid of unionfs, too :-)
> > 
> > My idea was that a unionfs *run* by root can recreate any auth object
> > that the client has and then authenticate with it against the unioned
> > directories.
> > 
> > If run by any other user then it can only recreate the intersection of
> > credentials between unionfs and the client.  This isn't ideal, but it
> > does ensure that unionfs doesn't accidentally grant the client any new
> > permissions by mistake.
> 
> From the theoretical point of view, there isn't really a problem,
> since unionfs should always grant permissions which are intersection
> between its permissions and the permissions of the calling client.
> Even if unionfs is running as root, it shouldn't give the calling
> client more permissions than they already have.  OTOH, bugs can bring
> about security problems in any case :-)

As explained above this assumes that the file permissions tell the
whole story.  The main problem with my suggestion is that it might be
too restrictive.  For instance, if user Alice wants to add an entry
to Bob's union directory.  Alice has permission to add to the unioned
directory because she's its owner but is not a member of the owning
group, Bob also has permission 

Re: website: background color in css

[Arne Babenhauserheide]

Am Dienstag, 17. November 2009 00:35:30 schrieb olafbuddenha...@gmx.net:
> It's actually perfectly OK
> to override text colors for emphasis in specific bits of text -- if you
> also override the background color *for these same bits of text*. The
> rest of the page can keep default colors for both text and background.
> 
> Too bad that hardly any web author sticks to this simple rule.

I tried that, and it looks really horrible - far worse than without 
background, because you get a snippet of white background in a dark text. 

A workaround I use at times when I can't read the text on some site is to 
simply select the text... 

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: website: background color in css

[Arne Babenhauserheide]

Am Dienstag, 17. November 2009 00:31:30 schrieb olafbuddenha...@gmx.net:
> No idea what you mean. If a user sets his default background color, we
> can safely assume that he also sets a matching default text color...

The Konqueror bug I cited is the problem, not the Hurd Website. 

Sadly it took me quite long to find out about it. 

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: Adding entries to a directory

[Sergiu Ivanov]

Hello,

On Tue, Nov 17, 2009 at 07:20:03PM +0100, Carl Fredrik Hammar wrote:
> On Tue, Nov 17, 2009 at 06:49:24PM +0200, Sergiu Ivanov wrote:
> > On Tue, Nov 17, 2009 at 01:15:59PM +0100, Carl Fredrik Hammar wrote:
>
> No, I think you're confusing authentication and access control.
> Authentication is the method used to establish the identity of a client,
> i.e. which user(s) and groups it is run by.  Access control is deciding
> which permissions the client has, typically based on which identity
> it has.

Yes, right!  I felt I was using the word ``authentication'' wrongly
:-( Thank you for reminding me the explanation.
 
> Authentication must be the same throughout the system to be useful.
> Access control is all up to the individual servers, and can be different
> throughout the system.  It is easy to imagine new types of access control,
> e.g. owner permissions for several users, or even a time lock that denies
> access after a certain date.  There are many possibilities which I think
> we should leave open.

Yeah, that's right.
 
> > > (But I might be missing something, perhaps POSIX says that regular file
> > > permissions should always be correct or something.)
> > 
> > Hm, why could POSIX say that regular file permissions may *not* be
> > correct? :-) I may be missing something, but it's hard for me to
> > imagine that POSIX file permissions were introduced with the thought
> > in mind that they may be wrong.
> 
> ``Correct'' wasn't really the right word, ``incomplete'' is more
> appropriate.  It seems that file permissions bits must always be present
> in some form, but that additional file access permissions may further
> restrict permissions:
> 
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_04
> 
> If this is the case then unionfs may inadvertently grant a permission
> that the unioned directory would've denied due to such an additional 
> mechanism.

Hm, I see.  I guess can understand you correctly now.
 
> > > My idea was that a unionfs *run* by root can recreate any auth object
> > > that the client has and then authenticate with it against the unioned
> > > directories.
> > > 
> > > If run by any other user then it can only recreate the intersection of
> > > credentials between unionfs and the client.  This isn't ideal, but it
> > > does ensure that unionfs doesn't accidentally grant the client any new
> > > permissions by mistake.
> > 
> > From the theoretical point of view, there isn't really a problem,
> > since unionfs should always grant permissions which are intersection
> > between its permissions and the permissions of the calling client.
> > Even if unionfs is running as root, it shouldn't give the calling
> > client more permissions than they already have.  OTOH, bugs can bring
> > about security problems in any case :-)
> 
> As explained above this assumes that the file permissions tell the
> whole story.  The main problem with my suggestion is that it might be
> too restrictive.  For instance, if user Alice wants to add an entry
> to Bob's union directory.  Alice has permission to add to the unioned
> directory because she's its owner but is not a member of the owning
> group, Bob also has permission because he is a member of the group,
> and others are not permitted.  The problem is that the intersection of
> their credentials will contain neither the user nor the group required to
> write to the directory, even thought both Alice and Bob has the necessary
> permissions on their own.

Hm, interesting situation, it didn't occur to my mind.  However, I'd
think that this problem is specific to any filesystem based on
standard POSIX permission bits.  Your idea was about creating an
alternate file access control mechanism, right?
 
> I just remembered that io_restrict_auth is described to do the exactly
> what we want.  However, it seems that in practice translators just make
> an intersection of the credentials, so it has the same problem.  :-(

Could you please give an example of how would you suggest to use
io_restrict_auth?  The fact is that unionfs, for instance (but I
believe other translator do similarly) does use io_restrict_auth, but
it indeed uses it to do the intersection.  (This is most probably what
you are talking about; I'm just restating it in more detail to avoid
ambiguity.)
 
Regards,
scolobb

Re: OT: automation

[Arne Babenhauserheide]

Hi, 

Am Montag, 16. November 2009 23:25:16 schrieb olafbuddenha...@gmx.net:
> Still not sure what you want to know. Are you asking for a technical
> design description? For a roadmap? Or yet something else?...

I just meant the question as a prompt to you, no explicit roadmap request or 
similar, just a "you have an idea, and I'm sure you also have ideas how to go 
about that" (for example the things you do with netrik). 

I'm sorry that I wasn't able to make that clear enough to have it work out ... 

Best wishes, 
Arne


signature.asc
Description: This is a digitally signed message part.

Re: Adding entries to a directory

[Carl Fredrik Hammar]

Hi,

On Tue, Nov 17, 2009 at 09:21:18PM +0200, Sergiu Ivanov wrote:
> > > > My idea was that a unionfs *run* by root can recreate any auth object
> > > > that the client has and then authenticate with it against the unioned
> > > > directories.
> > > > 
> > > > If run by any other user then it can only recreate the intersection of
> > > > credentials between unionfs and the client.  This isn't ideal, but it
> > > > does ensure that unionfs doesn't accidentally grant the client any new
> > > > permissions by mistake.
> > > 
> > > From the theoretical point of view, there isn't really a problem,
> > > since unionfs should always grant permissions which are intersection
> > > between its permissions and the permissions of the calling client.
> > > Even if unionfs is running as root, it shouldn't give the calling
> > > client more permissions than they already have.  OTOH, bugs can bring
> > > about security problems in any case :-)
> > 
> > As explained above this assumes that the file permissions tell the
> > whole story.  The main problem with my suggestion is that it might be
> > too restrictive.  For instance, if user Alice wants to add an entry
> > to Bob's union directory.  Alice has permission to add to the unioned
> > directory because she's its owner but is not a member of the owning
> > group, Bob also has permission because he is a member of the group,
> > and others are not permitted.  The problem is that the intersection of
> > their credentials will contain neither the user nor the group required to
> > write to the directory, even thought both Alice and Bob has the necessary
> > permissions on their own.
> 
> Hm, interesting situation, it didn't occur to my mind.  However, I'd
> think that this problem is specific to any filesystem based on
> standard POSIX permission bits.  Your idea was about creating an
> alternate file access control mechanism, right?

Well, this situation isn't a problem in the current implementation, so it
isn't specific to regular permission bits.  This is because Bob would use
his group membership to add the entry on Alice behalf, which he allows
because the permission bits state that she's the owner of the directory.

I don't so much want to create a new file access mechanism, as I
want to rely on the unioned directories own access mechanism, and let
them decide whether to allow Alice to add an entry.  As it is now,
unionfs implements an access policy which it *assumes* is the same as
the unioned directories.

> > I just remembered that io_restrict_auth is described to do the exactly
> > what we want.  However, it seems that in practice translators just make
> > an intersection of the credentials, so it has the same problem.  :-(
> 
> Could you please give an example of how would you suggest to use
> io_restrict_auth?  The fact is that unionfs, for instance (but I
> believe other translator do similarly) does use io_restrict_auth, but
> it indeed uses it to do the intersection.  (This is most probably what
> you are talking about; I'm just restating it in more detail to avoid
> ambiguity.)

1. Alice opens unionfs directory
2. unionfs opens unioned directories using Bob's credentials
3. unionfs restricts auth of directories to Alice's credentials
4. Alice adds entry
5, unionfs adds entry to whichever directory gets new entries

Notice how unionfs doesn't need to check whether Alice is permitted to
add the entry.  It simply relies on that the unioned directory does it.

Note that this has the problem I described.  But it wouldn't if
io_restrict_auth was defined to intersect the operations allowed by two
credentials instead of the credentials themselves.  Such a definition
would be more useful IMHO, but a separate project of course.

Also I looked up how unionfs uses io_restrict_auth, and I'm a bit
confused.  It seems it only restricts normal files with the client's
credentials.  I can't tell whether it then proxies the file or returns
it, but if it is returned then it should be reauthenticated by the client,
and then it is best to return a completely unauthenticated port, either by
not authenticating it at all, or restricting auth with empty credentials.

Regards,
  Fredrik

Re: Adding entries to a directory

[Sergiu Ivanov]

Hello,

On Tue, Nov 17, 2009 at 10:29:40PM +0100, Carl Fredrik Hammar wrote:
>
> > > As explained above this assumes that the file permissions tell the
> > > whole story.  The main problem with my suggestion is that it might be
> > > too restrictive.  For instance, if user Alice wants to add an entry
> > > to Bob's union directory.  Alice has permission to add to the unioned
> > > directory because she's its owner but is not a member of the owning
> > > group, Bob also has permission because he is a member of the group,
> > > and others are not permitted.  The problem is that the intersection of
> > > their credentials will contain neither the user nor the group required to
> > > write to the directory, even thought both Alice and Bob has the necessary
> > > permissions on their own.
> > 
> > Hm, interesting situation, it didn't occur to my mind.  However, I'd
> > think that this problem is specific to any filesystem based on
> > standard POSIX permission bits.  Your idea was about creating an
> > alternate file access control mechanism, right?
> 
> Well, this situation isn't a problem in the current implementation, so it
> isn't specific to regular permission bits.  This is because Bob would use
> his group membership to add the entry on Alice behalf, which he allows
> because the permission bits state that she's the owner of the directory.

Aha, I see.
 
> I don't so much want to create a new file access mechanism, as I
> want to rely on the unioned directories own access mechanism, and let
> them decide whether to allow Alice to add an entry.  As it is now,
> unionfs implements an access policy which it *assumes* is the same as
> the unioned directories.

Aha, so you are talking about removing access policy implementation
from unionfs and making unionfs check with the directory whether a
certain user is allowed to add entries to it?
 
> > > I just remembered that io_restrict_auth is described to do the exactly
> > > what we want.  However, it seems that in practice translators just make
> > > an intersection of the credentials, so it has the same problem.  :-(
> > 
> > Could you please give an example of how would you suggest to use
> > io_restrict_auth?  The fact is that unionfs, for instance (but I
> > believe other translator do similarly) does use io_restrict_auth, but
> > it indeed uses it to do the intersection.  (This is most probably what
> > you are talking about; I'm just restating it in more detail to avoid
> > ambiguity.)
> 
> 1. Alice opens unionfs directory
> 2. unionfs opens unioned directories using Bob's credentials
> 3. unionfs restricts auth of directories to Alice's credentials
> 4. Alice adds entry
> 5, unionfs adds entry to whichever directory gets new entries
> 
> Notice how unionfs doesn't need to check whether Alice is permitted to
> add the entry.  It simply relies on that the unioned directory does it.

I see.  The check is ``done'' by the directory, and unionfs simply
tries adding the entry and stops whenever a directory accepts the
entry or when it finished traversing the list of directories.
 
> Note that this has the problem I described.  But it wouldn't if
> io_restrict_auth was defined to intersect the operations allowed by two
> credentials instead of the credentials themselves.  Such a definition
> would be more useful IMHO, but a separate project of course.

It looks clear to me now.  Thanks for the detailed explanation :-)
 
> Also I looked up how unionfs uses io_restrict_auth, and I'm a bit
> confused.  It seems it only restricts normal files with the client's
> credentials.  I can't tell whether it then proxies the file or returns
> it, but if it is returned then it should be reauthenticated by the client,
> and then it is best to return a completely unauthenticated port, either by
> not authenticating it at all, or restricting auth with empty credentials.

unionfs does not proxy ports to normal files.  The necessity of
reauthentication arises from the fact that the credentials associated
with the port unionfs returns may not be the same as those of the
client, but only a subset of them, right?

Regards,
scolobb