Feeble attempt at using xattr gnu.translator

Feeble attempt at using xattr gnu.translator

[Jan Nieuwenhuizen]

Hello,

As part of the effort of creating vm-images for the Hurd using Guix, it
would be nice to use extended file attributes to set passive
translators.

In particular, it would be helpful if we could use

    setfattr --name=gnu.translator --value=/hurd/pfinet 1

That would allow us to boot right into Guile and skip a Bash script to
only to run

    settrans -c /servers/socket/1 /hurd/pflocal

Whether on GNU/Linux or on the Hurd (booted with
--x-xattr-translator-records and x-xattr-translator-records option in
fstab); almost nothing works.

The Hurd

    root@debian:~# cat /etc/fstab
    # /etc/fstab: static file system information.
    #
    # <file system> <mount point>   <type>  <options>       <dump>  <pass>
    /dev/hd0s2      /               ext2    defaults,x-xattr-translator-records 0       1
    /dev/hd0s1      none            swap    sw              0       0
    /dev/hd2        /media/cdrom0   iso9660 noauto          0       0
    root@debian:~# fsysopts /
    ext2fs --writable --no-inherit-dir-group --x-xattr-translator-records --store-type=typed device:hd0s2
    root@debian:~# ps -ef --width=1000 | grep ext2
     -     5     2   -  0:02.98 ext2fs --readonly --multiboot-command-line=root=device:hd0s2 --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd0s2 --x-xattr-translator-records

so that seems OK?  Still, nothing seems to work

    root@debian:~# touch 1
    root@debian:~# mknod 2 c 0 0
    root@debian:~# setfattr --name=gnu.translator --value=/hurd/pfinet 1
    setfattr: 1: Invalid argument
    root@debian:~# setfattr --name=gnu.translator --value=/hurd/pfinet 2
    setfattr: 2: Invalid argument
    root@debian:~# setfattr --name=gnu.author --value=/hurd/pfinet 1
    setfattr: 1: Invalid argument
    root@debian:~# setfattr --name=gnu.author --value=/hurd/pfinet 2
    setfattr: 2: Invalid argument
    root@debian:~# setfattr --name=user.translator --value=/hurd/pfinet 1
    setfattr: 1: Operation not supported
    root@debian:~# setfattr --name=user.translator --value=/hurd/pfinet 2
    setfattr: 2: Operation not supported

On GNU/Linux, I only managed to set user.X, not gnu.translator

    root@dundal ~# touch 1
    root@dundal ~# mknod 2 c 0 0
    root@dundal ~# setfattr --name=gnu.translator --value=/hurd/pfinet 1
    setfattr: 1: Operation not supported
    root@dundal ~# setfattr --name=gnu.translator --value=/hurd/pfinet 2
    setfattr: 2: Operation not supported
    root@dundal ~# setfattr --name=gnu.author --value=/hurd/pfinet 1
    setfattr: 1: Operation not supported
    root@dundal ~# setfattr --name=gnu.author --value=/hurd/pfinet 2
    setfattr: 2: Operation not supported
    root@dundal ~# setfattr --name=user.translator --value=/hurd/pfinet 1
    root@dundal ~# setfattr --name=user.translator --value=/hurd/pfinet 2
    setfattr: 2: Operation not permitted

only one command succeeds, but that's next to useless (well, it suggests touch
could work and we don't need mknod).

This

    https://lists.gnu.org/archive/html/bug-hurd/2004-02/msg00108.html

is the only interesting piece of information I found; down the thread
there is a suggestion to try upstreaming.  I looked at the Linux sources
They seem to suggest that only a couple of namespaces are allowed (and
"gnu" is not one of them) but find them hard to read.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Feeble attempt at using xattr gnu.translator

[Samuel Thibault]

Hello,

Did you have a look at Shengyu Zhang's work on xattr? That's about
summer 2016. Also see glibc/sysdeps/mach/hurd/setxattr.c which
translates gnu attributes into RPC calls, and then again in the
translators's diskfs_set_translator. See for instance in
hurd/ext2fs/inode.c's diskfs_set_translator, it looks at

 if (EXT2_HAS_COMPAT_FEATURE (sblock, EXT2_FEATURE_COMPAT_EXT_ATTR)
      && use_xattr_translator_records)

Samuel

Re: Feeble attempt at using xattr gnu.translator

[Jan Nieuwenhuizen]

Samuel Thibault writes:

Hello Samuel,

> Did you have a look at Shengyu Zhang's work on xattr? That's about
> summer 2016.

Ah, that's a helpful pointer.  What I notice is that Shengyu's last
message says "not merged yet", to which Richard Braun responds

    https://lists.gnu.org/archive/html/bug-hurd/2016-08/msg00095.html

    "we'll have more time in September to really dive into the code,
    finish the review and merge it."

It got merged, but I'm not sure about the "finish" bit; Justus Winter
disabled it by default (not a great sign), and GSoC 2017 mentions:
"finishing the xattr work"

    https://lists.gnu.org/archive/html/bug-hurd/2017-01/msg00016.html

I cannot find any more meta data, documentation or tests...

> Also see glibc/sysdeps/mach/hurd/setxattr.c which
> translates gnu attributes into RPC calls, and then again in the
> translators's diskfs_set_translator. See for instance in
> hurd/ext2fs/inode.c's diskfs_set_translator, it looks at
>
>  if (EXT2_HAS_COMPAT_FEATURE (sblock, EXT2_FEATURE_COMPAT_EXT_ATTR)
>       && use_xattr_translator_records)

I noticed the --x-xattr-translator-records before but after reading some
more code, I got a little bit further

glibc/hurd/xattr.c has

   gnu.translator	empty if no passive translator
			translator and arguments: "/hurd/foo\0arg1\0arg2\0"

ah...so there's a nice hack (way??) to also pass arguments...and then

hurd/libdiskfs/file-set-trans.c has

diskfs_S_file_set_translator (struct protid *cred,
[...]
  if (passivelen && passive[passivelen - 1])
    return EINVAL;

hmm; so even when there are no arguments, VALUE must end with 0?!
Okay...

--8<---------------cut here---------------start------------->8---
root@debian:~# touch 1
root@debian:~# setfattr --name=gnu.translator --value=/hurd/pflocal 1
setfattr: 1: Invalid argument
root@debian:~# setfattr --name=gnu.translator --value='/hurd/pflocal\0' 1
root@debian:~# showtrans 1
/hurd/pflocal
--8<---------------cut here---------------end--------------->8---

...so "something" works.

Sadly, this trick does not work on GNU/Linux.  I'm afraid this hasn't
been upstreamed and we would have to debug linux and/or create a patch
for setxattr to accept "gnu." on "Hurd" type file systems.  Thoughts?

Also, some other things also don't work

--8<---------------cut here---------------start------------->8---
root@debian:~# getfattr --name=gnu.translator 1
1: gnu.translator: Operation not supported
root@debian:~# setfattr --name=gnu.translator --value='/geert/pflocal\0' 1
setfattr: 1: Operation not supported
root@debian:~# setfattr --remove=gnu.translator 1
setfattr: 1: Operation not supported
--8<---------------cut here---------------end--------------->8---

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Feeble attempt at using xattr gnu.translator

[Samuel Thibault]

Jan Nieuwenhuizen, le lun. 11 mai 2020 10:33:53 +0200, a ecrit:
>    gnu.translator	empty if no passive translator
> 			translator and arguments: "/hurd/foo\0arg1\0arg2\0"
> 
> ah...so there's a nice hack (way??) to also pass arguments...

? It's not hack, it's how it's passed on the process main() stack anyway.

> diskfs_S_file_set_translator (struct protid *cred,
> [...]
>   if (passivelen && passive[passivelen - 1])
>     return EINVAL;
> 
> hmm; so even when there are no arguments, VALUE must end with 0?!

That

> root@debian:~# setfattr --name=gnu.translator --value='/hurd/pflocal\0' 1
> root@debian:~# showtrans 1
> /hurd/pflocal
> --8<---------------cut here---------------end--------------->8---
> 
> ...so "something" works.

Good :)

> Sadly, this trick does not work on GNU/Linux.  I'm afraid this hasn't
> been upstreamed and we would have to debug linux and/or create a patch
> for setxattr to accept "gnu." on "Hurd" type file systems.  Thoughts?

Well, this has to be done, yes, I don't know what else to add :)

Samuel

Re: Feeble attempt at using xattr gnu.translator

[Samuel Thibault]

Samuel Thibault, le lun. 11 mai 2020 10:42:08 +0200, a ecrit:
> > diskfs_S_file_set_translator (struct protid *cred,
> > [...]
> >   if (passivelen && passive[passivelen - 1])
> >     return EINVAL;
> > 
> > hmm; so even when there are no arguments, VALUE must end with 0?!
> 
> That

That's a bit sad, but I'm not so surprised either. I don't remember if
that was discussed at the time.

Samuel

Re: Feeble attempt at using xattr gnu.translator

[Jan Nieuwenhuizen]

Samuel Thibault writes:

> Samuel Thibault, le lun. 11 mai 2020 10:42:08 +0200, a ecrit:
>> > diskfs_S_file_set_translator (struct protid *cred,
>> > [...]
>> >   if (passivelen && passive[passivelen - 1])
>> >     return EINVAL;
>> > 
>> > hmm; so even when there are no arguments, VALUE must end with 0?!
>> 
>> That
>
> That's a bit sad, but I'm not so surprised either. I don't remember if
> that was discussed at the time.

At first glance it felt like a bug/non-finished thing; setttrans does
not require the user to resort to \0-hackery.

Of course, setfattr is a generic tool; so nothing can be done there to
make this frienlier; I'm not sure if something could be done on the hurd
side.  Could be nice, not sure.

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Feeble attempt at using xattr gnu.translator

[Samuel Thibault]

Jan Nieuwenhuizen, le lun. 11 mai 2020 10:53:58 +0200, a ecrit:
> Samuel Thibault writes:
> 
> > Samuel Thibault, le lun. 11 mai 2020 10:42:08 +0200, a ecrit:
> >> > diskfs_S_file_set_translator (struct protid *cred,
> >> > [...]
> >> >   if (passivelen && passive[passivelen - 1])
> >> >     return EINVAL;
> >> > 
> >> > hmm; so even when there are no arguments, VALUE must end with 0?!
> >> 
> >> That
> >
> > That's a bit sad, but I'm not so surprised either. I don't remember if
> > that was discussed at the time.
> 
> At first glance it felt like a bug/non-finished thing; setttrans does
> not require the user to resort to \0-hackery.

It does not because settrans is supposed to *be* the user-visible
interface. setfattr is not supposed to be.

Samuel