<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>75825</bug_id>
          
          <creation_ts>2004-12-27 10:42 0000</creation_ts>
          <short_desc>captive: mount as user</short_desc>
          <delta_ts>2005-02-13 13:09:16 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Applications</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>77239</blocked>
          
          <everconfirmed>1</everconfirmed>
          <reporter>bettlertho@sis.unibe.ch</reporter>
          <assigned_to>genstef@gentoo.org</assigned_to>
          <cc>A.Schneider@magicspace.de</cc>
    
    <cc>jonas.baehr@web.de</cc>
    
    <cc>lpetersen@gmx.net</cc>
    
    <cc>stony@gmx.org</cc>

      

      
          <long_desc isprivate="0">
            <who>bettlertho@sis.unibe.ch</who>
            <bug_when>2004-12-27 10:42:52 0000</bug_when>
            <thetext>common users should also be able to mount captive-partitions accordingly to the definitions
in the /etc/fstab.

Currently neither option user(s) nor uid=&lt;name&gt; works as it should.

A user is only able to mount a device if
1) device is read/write for user
2) mount point is read/write for user

As further error the own user can&apos;t even umount it right after:
umount: /mnt/captive mount disagrees with the fstab

/etc/fstab:
/dev/hda1 /mnt/captive captive-ntfs users,uid=1000 0 0

/etc/mtab:
lufis /mnt/captive fuse rw,nosuid,nodev,user=&lt;me&gt; 0 0

one user can&apos;t read another users mount, neither root can. In my case I&apos;d like to indicate
that all / multiple users have access to the mounted device. (i.e. with users / uid= )

User support should be improved, but I don&apos;t see how to do this best.

Thanks anyway for integrating it into portage and supporting it. I really like your work! Great

Thomas Bettler</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genstef@gentoo.org</who>
            <bug_when>2005-01-02 05:02:45 0000</bug_when>
            <thetext>Created an attachment (id=47369)
lufis-allow-uid-and-gid.patch

patch for lufis to take uid= and gid= parameters, when the program returns
uid=1 or gid=1.
It has no check if the value is valid.

Please test and comment. A valid fstab entry woudl look like:

/dev/hda1 /mnt/captive captive-ntfs defaults,uid=1000,gid=100 0 0
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>bettlertho@sis.unibe.ch</who>
            <bug_when>2005-01-02 06:32:14 0000</bug_when>
            <thetext>Hm, nope. I tried your patch but it didn&apos;t help.

I still have to mount the device as the user.

Why do you check uid/gid=1 ? Didn&apos;t you mean 0 (root,wheel)?
But I also tried to check uid/gid against 0 - still negative.

In my eyes it would be more consistent to check if uid/gid options are given/valid and depending on that forward these values.

Maybe there is an other part (of lufis or maybe fuse or lufs or captive) involved in setting uid/gid permissions.

If I can help you somehow let me know, I will provide you all the things you&apos;d like.
But I&apos;m no hacker and therefore I&apos;m no way able to fix this bug myself.

Anyway Tanks A Lot for your support so far.
Your advise was really quick and half way helpful on our way to fix it.

Lot of Greetings and a happy new year.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genstef@gentoo.org</who>
            <bug_when>2005-01-02 06:46:43 0000</bug_when>
            <thetext>What permissions do you have currently? For me it was always the bin group and user, and this patch tries to attach the uid= user when the uid and/or gid is 1(bin).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>A.Schneider@magicspace.de</who>
            <bug_when>2005-01-02 07:32:02 0000</bug_when>
            <thetext>I also tried the patch now. At my system it is working very good.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>marcgallagher@gmail.com</who>
            <bug_when>2005-01-05 21:17:59 0000</bug_when>
            <thetext>
Two questions:

1) I hate to pollute bugzilla with n00b questions, but how do I apply the patch?  Do I just stick it in the files folder and add a epatch line to the .ebuild?

2) Looking over the patch (and only the patch mind you, as I have no idea where emerge downloads actual files to in order to look at the source), I see these lines:

+    // Take uid= and gid= vars when the filesystem returns 1
+    if(fattr.f_uid == (uid_t) 1) {
+        lu_opt_getint(&amp;lu_cfg, &quot;MOUNT&quot;, &quot;uid&quot;, &amp;option_uid, 0);
+        fattr.f_uid = (uid_t) option_uid;
+    }
+
+    if(fattr.f_gid == (gid_t) 1) {
+        lu_opt_getint(&amp;lu_cfg, &quot;MOUNT&quot;, &quot;gid&quot;, &amp;option_gid, 0);
+        fattr.f_gid = (gid_t) option_gid;
+    }

My pure guess as to how lu_opt_getint() works would be that the last param is a default value.  If so, souldn&apos;t the above lines of code be reduced to:

lu_opt_getint(&amp;lu_cfg, &quot;MOUNT&quot;, &quot;uid&quot;, &amp;fattr.f_uid, 0);
lu_opt_getint(&amp;lu_cfg, &quot;MOUNT&quot;, &quot;gid&quot;, &amp;fattr.f_gid, 0);

If my shot in the dark guess is right, this would set the default owner/group to 0 (root), which seems to be a much better default for the owner/group id&apos;s than whatever random numbers NT makes up.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>marcgallagher@gmail.com</who>
            <bug_when>2005-01-05 21:20:54 0000</bug_when>
            <thetext>On second glance, option_uid and option_gid may still be needed as temp values, but I still suspect we can get rid of the check for 1 as a magic number and always default to root owning the files.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genstef@gentoo.org</who>
            <bug_when>2005-01-06 00:36:46 0000</bug_when>
            <thetext>Thats one of the problems with the patch .. the last param is no default param, but instead the type of the string-&gt;int conversion. I have no default param at all so it takes some nonsense value from the memory when I dont give uid= and gid=.

And sorry, your simplification wont work, because the type is not the same, the type in brackets in the line below is type conversion.

Another problem is, that you cant even read the permissions as user (with or without this patch). They are correct .. but this helps little, when the user cant see and use it.

How to apply the patch?
# emerge lufis
[CTRL+Z] after source unpacked.
# cd /var/tmp/portage/lufis-0.2/work/lufis-0.2
# patch -p1 &lt; /path/to/patch
# fg</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>bettlertho@sis.unibe.ch</who>
            <bug_when>2005-01-07 04:12:00 0000</bug_when>
            <thetext>Still no success, here.
the uid/gid apply, but there is another problem:

if I mount /mnt/captive as root:
and as root &gt;# ls -l /mnt/captive
rw-rw-rw-     1000 100    file1
...
but as user (uid=1000)
&gt;$ ls -l /mnt/captive
ls: /mnt/captive: Permission denied

if I mount /mnt/captive as user everthing works ok and /mnt/captive doen&apos;t deny the permission.

Any ideas what might be wrong here?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genstef@gentoo.org</who>
            <bug_when>2005-01-07 09:41:50 0000</bug_when>
            <thetext>Created an attachment (id=47868)
lufis-allow-uid-and-gid.patch

Better patch, it now avoids strange values if one only gives one of uid= or
gid= or nothing.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genstef@gentoo.org</who>
            <bug_when>2005-01-07 09:44:56 0000</bug_when>
            <thetext>Created an attachment (id=47869)
/sbin/mount.captive

New /sbin/mount.captive

allows root to mount with full user r/w access, and also allows the user to
umount (if option users is in fstab)
What it not aallows, is mounting as user (yet to come ..)

My fstab entry now:
/dev/hda3		/mnt/captive	captive-ntfs   
defaults,noauto,rw,uid=stefan,users 0 0</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genstef@gentoo.org</who>
            <bug_when>2005-01-26 11:28:18 0000</bug_when>
            <thetext>please test it and comment, tell me that it works for you or give some feedback ..</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lpetersen@gmx.net</who>
            <bug_when>2005-01-27 05:55:43 0000</bug_when>
            <thetext>Thank you, Stefan! This seems to work for me as far as it should.

Using sys-fs/captive-1.1.5-r1 and sys-fs/lufis-0.2 with your second patch and your new /sbin/mount.captive, I CAN
* mount my NTFS partition as root (but not as user, as you said)
* properly set uid and/or gid by /etc/fstab entry
* unmount my NTFS partition as root and as ANY user
* read from and write to any directory or file as root
* read from and write to directories/files as a normal user according to set permissions

I can NOT
* chmod directories (an &quot;Operation not permitted&quot; error message is issued)
* chmod files (no error message, but no effect either)

FWIW, this is my /etc/fstab entry:
/dev/hdb1  /mnt/winxp  captive-ntfs  rw,users,uid=lars,gid=users,noatime,noauto 0 0
and this is the corresponding output line of `mount`:
/dev/hdb1 on /mnt/winxp type fuse (rw,nosuid,nodev,allow_other,default_permissions)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>alistair@stuffthatworks.com.au</who>
            <bug_when>2005-02-05 05:30:39 0000</bug_when>
            <thetext>Stefan - this worked fine for me!

Thanks for all the hard work, i now have full access to NTFS.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>A.Schneider@magicspace.de</who>
            <bug_when>2005-02-05 09:20:39 0000</bug_when>
            <thetext>It works good here too! :)
Tnx for your work.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genstef@gentoo.org</who>
            <bug_when>2005-02-05 11:46:41 0000</bug_when>
            <thetext>
Is the captive version from
http://dev.gentoo.org/~genstef/files/overlay/sys-fs/captive/
ok for you?

This will also solve bug 77239 as there is no longer a dependancy on gnome-vfs-httpcaptive.
I solved it with an static tarball, if it is not yet on the mirrors, you can get it here:
http://dev.gentoo.org/~genstef/files/overlay/captive-install-static-1.1.5.tar.bz2</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lpetersen@gmx.net</who>
            <bug_when>2005-02-09 00:40:21 0000</bug_when>
            <thetext>Emerged your ebuild, which pulled in the following:
dev-libs/glib-2.6.2
sys-fs/fuse-2.2
sys-fs/lufis-0.3
sys-fs/captive-1.1.5-r2

Everything works as it used to, PLUS:
I can mount as a normal user now, after creating a /etc/fuse.conf with a line &apos;user_allow_other&apos;.

Anything else we should test?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>genstef@gentoo.org</who>
            <bug_when>2005-02-13 13:09:16 0000</bug_when>
            <thetext>Thank you all for helping on this bug with testing, its now finally in the tree.</thetext>
          </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>47369</attachid>
            <date>2005-01-02 05:02 0000</date>
            <desc>lufis-allow-uid-and-gid.patch</desc>
            <filename>lufis-allow-uid-and-gid.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtcHVyIGx1ZmlzLTAuMi5vcmlnL2x1ZmlzLmMgbHVmaXMtMC4yL2x1ZmlzLmMKLS0tIGx1
ZmlzLTAuMi5vcmlnL2x1ZmlzLmMJMjAwNC0wMy0wOSAxOTowOTo1Ny4wMDAwMDAwMDAgKzAxMDAK
KysrIGx1ZmlzLTAuMi9sdWZpcy5jCTIwMDUtMDEtMDIgMTM6MzU6MjQuMTY0OTU3NDU2ICswMTAw
CkBAIC0yNjgsMTEgKzI2OCwyNCBAQCBzdGF0aWMgaW50IGx1X2dldGF0dHIoY29uc3QgY2hhciAq
cGF0aCwgCiB7CiAgICAgc3RydWN0IGx1ZnNfZmF0dHIgZmF0dHI7CiAgICAgaW50IHJlczsKKyAg
ICBsb25nIGludCBvcHRpb25fdWlkOworICAgIGxvbmcgaW50IG9wdGlvbl9naWQ7CiAgICAgCiAg
ICAgcmVzID0gbHVfZ2V0YXR0cl9uYXRpdmUocGF0aCwgJmZhdHRyKTsKICAgICBpZihyZXMgPCAw
KQogICAgICAgICByZXR1cm4gcmVzOwogCisgICAgLy8gVGFrZSB1aWQ9IGFuZCBnaWQ9IHZhcnMg
d2hlbiB0aGUgZmlsZXN5c3RlbSByZXR1cm5zIDEKKyAgICBpZihmYXR0ci5mX3VpZCA9PSAodWlk
X3QpIDEpIHsKKyAgICAgICAgbHVfb3B0X2dldGludCgmbHVfY2ZnLCAiTU9VTlQiLCAidWlkIiwg
Jm9wdGlvbl91aWQsIDApOworICAgICAgICBmYXR0ci5mX3VpZCA9ICh1aWRfdCkgb3B0aW9uX3Vp
ZDsKKyAgICB9CisKKyAgICBpZihmYXR0ci5mX2dpZCA9PSAoZ2lkX3QpIDEpIHsKKyAgICAgICAg
bHVfb3B0X2dldGludCgmbHVfY2ZnLCAiTU9VTlQiLCAiZ2lkIiwgJm9wdGlvbl9naWQsIDApOwor
ICAgICAgICBmYXR0ci5mX2dpZCA9IChnaWRfdCkgb3B0aW9uX2dpZDsKKyAgICB9CisKICAgICBz
dGJ1Zi0+c3RfbW9kZSAgICA9IGZhdHRyLmZfbW9kZTsKICAgICBzdGJ1Zi0+c3RfbmxpbmsgICA9
IGZhdHRyLmZfbmxpbms7CiAgICAgc3RidWYtPnN0X3VpZCAgICAgPSBmYXR0ci5mX3VpZDsK
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>47868</attachid>
            <date>2005-01-07 09:41 0000</date>
            <desc>lufis-allow-uid-and-gid.patch</desc>
            <filename>lufis-allow-uid-and-gid.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtcHVyIGx1ZmlzLTAuMi5vcmlnL2x1ZmlzLmMgbHVmaXMtMC4yL2x1ZmlzLmMKLS0tIGx1
ZmlzLTAuMi5vcmlnL2x1ZmlzLmMJMjAwNC0wMy0wOSAxOTowOTo1Ny4wMDAwMDAwMDAgKzAxMDAK
KysrIGx1ZmlzLTAuMi9sdWZpcy5jCTIwMDUtMDEtMDcgMTc6MzQ6NTcuMTU3MzcyNDg4ICswMTAw
CkBAIC0yNjgsMTEgKzI2OCwzMCBAQCBzdGF0aWMgaW50IGx1X2dldGF0dHIoY29uc3QgY2hhciAq
cGF0aCwgCiB7CiAgICAgc3RydWN0IGx1ZnNfZmF0dHIgZmF0dHI7CiAgICAgaW50IHJlczsKKyAg
ICBsb25nIGludCBvcHRpb25fdWlkOworICAgIGxvbmcgaW50IG9wdGlvbl9naWQ7CiAgICAgCiAg
ICAgcmVzID0gbHVfZ2V0YXR0cl9uYXRpdmUocGF0aCwgJmZhdHRyKTsKICAgICBpZihyZXMgPCAw
KQogICAgICAgICByZXR1cm4gcmVzOwogCisgICAgLy8gVGFrZSB1aWQ9IGFuZCBnaWQ9IHZhcnMg
d2hlbiB0aGUgZmlsZXN5c3RlbSByZXR1cm5zIDEKKyAgICBpZihmYXR0ci5mX3VpZCA9PSAodWlk
X3QpIDEpIHsKKyAgICAgICAgaWYoIWx1X29wdF9nZXRpbnQoJmx1X2NmZywgIk1PVU5UIiwgInVp
ZCIsICZvcHRpb25fdWlkLCAwKSkKKwkJZmF0dHIuZl91aWQgPSAodWlkX3QpIG9wdGlvbl91aWQ7
CisJZWxzZQorCQkvLyBkZWZhdWx0IHRvIDAgKHJvb3QpIHdoZW4gbm8gYXJndW1lbnQgd2FzIHN1
cHBsaWVkCisJCWZhdHRyLmZfdWlkID0gKHVpZF90KSAwOworICAgIH0KKworICAgIGlmKGZhdHRy
LmZfZ2lkID09IChnaWRfdCkgMSkgeworICAgICAgICBpZighbHVfb3B0X2dldGludCgmbHVfY2Zn
LCAiTU9VTlQiLCAiZ2lkIiwgJm9wdGlvbl9naWQsIDApKQorCQlmYXR0ci5mX2dpZCA9IChnaWRf
dCkgb3B0aW9uX2dpZDsKKwllbHNlCisJCS8vIGRlZmF1bHQgdG8gMCAocm9vdCkgd2hlbiBubyBh
cmd1bWVudCB3YXMgc3VwcGxpZWQKKwkJZmF0dHIuZl9naWQgPSAoZ2lkX3QpIDA7CisgICAgfQor
CiAgICAgc3RidWYtPnN0X21vZGUgICAgPSBmYXR0ci5mX21vZGU7CiAgICAgc3RidWYtPnN0X25s
aW5rICAgPSBmYXR0ci5mX25saW5rOwogICAgIHN0YnVmLT5zdF91aWQgICAgID0gZmF0dHIuZl91
aWQ7Cg==
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>47869</attachid>
            <date>2005-01-07 09:44 0000</date>
            <desc>/sbin/mount.captive</desc>
            <filename>mount.captive</filename>
            <type>text/plain</type>
            <data encoding="base64">IyEgL3Vzci9iaW4vcGVybCAtdwojIAojICRJZDogbW91bnQuY2FwdGl2ZS5pbix2IDEuMTcgMjAw
My8xMi8wNiAxNTowODoyNSBzaG9ydCBFeHAgJAojIEV4dGVybmFsIG1vdW50IGNvbW1hbmQgZm9y
IG1vdW50KDgpIHRvIGludGVyZmFjZSBsdWZzZCgxKQojIENvcHlyaWdodCAoQykgMjAwMyBKYW4g
S3JhdG9jaHZpbCA8cHJvamVjdC1jYXB0aXZlQGphbmtyYXRvY2h2aWwubmV0PgojIAojIFRoaXMg
cHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3Ig
bW9kaWZ5CiMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSBhcyBwdWJsaXNoZWQgYnkKIyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBleGFj
dGx5IHZlcnNpb24gMiBvZiBKdW5lIDE5OTEgaXMgcmVxdWlyZWQKIyAKIyBUaGlzIHByb2dyYW0g
aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKIyBidXQg
V0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBv
ZgojIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4g
IFNlZSB0aGUKIyBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgoj
IAojIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlCiMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8g
dGhlIEZyZWUgU29mdHdhcmUKIyBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1
aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBCgoKdXNlIHN0cmljdDsKdXNlIENh
cnAgcXcoY2x1Y2sgY29uZmVzcyk7CnVzZSBHZXRvcHQ6Okxvbmc7CiMgRG8gbm90IHVzZSBhbnkg
bm9uLWNvcmUgUGVybCBtb2R1bGVzIGhlcmUuCiMgQmUgcGVybC01LjAgY29tcGF0aWJsZSAoaXMg
aXQgbmVlZGVkIGlmIHdlIHJlcXVpcmUgTGludXgga2VybmVsID49IDIuNCA/KQoKCm15ICR2YXJk
aXI9Jy92YXIvbGliL2NhcHRpdmUnOwokdmFyZGlyPX5zI1wkXFF7cHJlZml4fVxFIycvdXNyJzsj
Z2U7CiR2YXJkaXI9Ii92YXIvbGliL2NhcHRpdmUiIGlmICR2YXJkaXI9fi9eQC87Cm15ICRsdWZz
ZF9iaW49Ii91c3IvYmluL2x1ZmlzIjsKbXkgJGNhcHRpdmVfc2FuZGJveF9zZXJ2ZXJfYmluPSck
e2V4ZWNfcHJlZml4fS9zYmluL2NhcHRpdmUtc2FuZGJveC1zZXJ2ZXInOwokY2FwdGl2ZV9zYW5k
Ym94X3NlcnZlcl9iaW49fnMjXCRcUXtleGVjX3ByZWZpeH1cRSMnJHtwcmVmaXh9JzsjZ2U7CiRj
YXB0aXZlX3NhbmRib3hfc2VydmVyX2Jpbj1+cyNcJFxRe3ByZWZpeH1cRSMnL3Vzcic7I2dlOwok
Y2FwdGl2ZV9zYW5kYm94X3NlcnZlcl9iaW49Ii91c3Ivc2Jpbi9jYXB0aXZlLXNhbmRib3gtc2Vy
dmVyIiBpZiAkY2FwdGl2ZV9zYW5kYm94X3NlcnZlcl9iaW49fi9eQC87CgoKbXkgJE1FPSgkMD1+
bSMoW14vXSopJCMpWzBdIG9yIGRpZSAiQ2Fubm90IGRldGV0ZWN0IG15IGJhc2VuYW1lIGZyb206
ICQwIjsKbXkgJGZzbmFtZT0kTUU7CiRmc25hbWU9fnMvXm1vdW50Wy5dY2FwdGl2ZS0vLyBvciBk
aWUgIkNhbm5vdCBkZXRlY3QgY2FwdGl2ZSBmaWxlc3lzdGVtIG1vZHVsZSBmcm9tIG15IG5hbWU6
ICRmc25hbWUiOwpteSAkaW1hZ2U9c2hpZnQgQEFSR1Ygb3IgZGllICJNaXNzaW5nIGFyZ3ZbMV06
IGRldmljZSBvciBpbWFnZSBwYXRobmFtZSI7Ci1yICRpbWFnZSBvciBkaWUgIkltYWdlIHBhdGhu
YW1lIG5vdCByZWFkYWJsZTogJGltYWdlIjsKd2FybiAid2FybmluZzogJy1vIGxvb3AnIGlzIG5v
dCBuZWNjZXNzYXJ5IGZvciBDYXB0aXZlIGZpbGVzeXN0ZW0gbW91bnRzIgoJCWlmICRpbWFnZT1+
bSNeL2Rldi9sb29wIzsKbXkgJGRpcj1zaGlmdCBAQVJHViBvciBkaWUgIk1pc3NpbmcgYXJndlsy
XTogbW91bnQgcG9pbnQgZGlyZWN0b3J5IjsKLWQgJGRpciBvciBkaWUgIk1vdW50IHBvaW50IGRp
cmVjdG9yeSBub3QgYSB2YWxpZCBkaXJlY3Rvcnk6ICRkaXIiOwpzaGlmdCBAQVJHViBpZiBteSAk
bm9tdGFiID0kQVJHVlswXSAmJiAkQVJHVlswXSBlcSAiLW4iOwpzaGlmdCBAQVJHViBpZiBteSAk
dmVyYm9zZT0kQVJHVlswXSAmJiAkQVJHVlswXSBlcSAiLXYiOwpteSAkb289IiI7CmRvIHsgc2hp
ZnQgQEFSR1Y7ICRvbz1zaGlmdCBAQVJHVjsgfSBpZiAkQVJHVlswXSAmJiAkQVJHVlswXSBlcSAi
LW8iOwpkaWUgIkV4Y2Vzc2l2ZSBhcmd1bWVudHM6IEBBUkdWIiBpZiBAQVJHVjsKCnN1YiBkaWVf
aW5zdGFsbAp7CglkaWUKIllvdSBzaG91bGQgcnVuIGNhcHRpdmUtaW5zdGFsbC1hY3F1aXJlKDEp
IG9mICdjYXB0aXZlLWluc3RhbGwnIHBhY2thZ2UsCm90aGVyd2lzZSB5b3UgY2FuIGFsc28gYWNx
dWlyZSB0aGlzIGZpbGUgZnJvbSBVUkw6Cmh0dHA6Ly93d3cubWljcm9zb2Z0LmNvbS9XaW5kb3dz
WFAvcHJvL2Rvd25sb2Fkcy9zZXJ2aWNlcGFja3Mvc3AxL2NoZWNrZWRidWlsZC5hc3AKIjsKfQoK
bXkgJGZpbGVzeXN0ZW09JHZhcmRpci4iLyIuJGZzbmFtZS4iLnN5cyI7CmlmICghLXIgJGZpbGVz
eXN0ZW0pIHsKCXdhcm4gIlczMiBmaWxlc3lzdGVtIC5zeXMgbW9kdWxlIG5vdCBmb3VuZDogJGZp
bGVzeXN0ZW0iOwoJZGllX2luc3RhbGwoKTsKCX0KbXkgJG50b3Nrcm5sPSR2YXJkaXIuIi9udG9z
a3JubC5leGUiOwppZiAoIS1yICRudG9za3JubCkgewoJd2FybiAiVzMyIG50b3Nrcm5sLmV4ZSBu
b3QgZm91bmQ6ICRudG9za3JubCI7CglkaWVfaW5zdGFsbCgpOwoJfQoKIyBLZWVwIEBvcHRfY2Fw
dGl2ZSBvcmRlcmluZwojIHRvIGxldCB0aGUgb3B0aW9ucyBiZSBvdmVycmlkYWJsZSBieSB1c2Vy
IChzdWNoIGFzICdybycpLgpteSBAb3B0X2NhcHRpdmU9KCk7Cm15IEBvcHRfbHVmcz0oKTsKbXkg
JG9wdF9mb3JjZTsKbXkgJG9wdF9yd21vZGU9Ii0tYmxpbmQiOwpmb3IgKHNwbGl0IC8sLywkb28p
IHsKCSRfPSItLSRfIiBpZiAkXyBlcSAicm8iIHx8ICRfIGVxICJydyI7Cgkkb3B0X3J3bW9kZT0k
XyBpZiAvXi0tKD86cm98cnd8YmxpbmQpJC87Cgkkb3B0X2ZvcmNlPTEgaWYgJF8gZXEgImZvcmNl
IjsKCXB1c2ggQG9wdF9jYXB0aXZlLCRfIGlmICAvXi0tLzsKCXB1c2ggQG9wdF9sdWZzLCRfICAg
IGlmICEvXi0tLzsKCX0KCiMgU2hhbWVsZXNzIGFkdmVydGlzZW1lbnQ6CmlmICgkZnNuYW1lIGVx
ICJudGZzIikgewoJZm9yIG15ICRmaCAoKlNUREVSUiwqU1RET1VUKSB7CgkJaWYgKC10ICRmaCkg
ewoJCQlwcmludCAkZmggJ0NhcHRpdmUgTlRGUyB2MS4xLjUuICBDaGVjayBhIG5ldyB2ZXJzaW9u
IGF0OiBodHRwOi8vd3d3LmphbmtyYXRvY2h2aWwubmV0LycuIlxuIjsKCQkJbGFzdDsKCQkJfQoJ
CX0KCX0KCmlmICghJG9wdF9mb3JjZSkgewoJbG9jYWwgKk1UQUI7CglpZiAoIW9wZW4gTVRBQiwi
L2V0Yy9tdGFiIikgewoJCXdhcm4gIkNhbm5vdCBvcGVuIC9ldGMvbXRhYjogJCEiOwoJCX0KCWVs
c2UgewoJCWxvY2FsICQvPXVuZGVmKCk7CgkJbXkgJG10YWI9PE1UQUI+OwoJCWNsb3NlIE1UQUI7
CgkJZGllICIiCgkJCQkJCS4iJE1FOiAkaW1hZ2UgYWxyZWFkeSBtb3VudGVkXG4iCgkJCQkJCS4i
JE1FOiBhY2NvcmRpbmcgdG8gbXRhYiwgJGltYWdlIGlzIG1vdW50ZWQgb24gJDFcbiIKCQkJCQkJ
LiIkTUU6IFVzZSAnLW8gZm9yY2UnIHRvIG1vdW50IHRoZSBpbWFnZSBub3R3aXRoc3RhbmRpbmcu
XG4iCgkJCQlpZiAkbXRhYj1+L15cUSRpbWFnZVxFXHMrKFxTKykvbTsKCQl9Cgl9Cgokb289IiIK
CQkuImZzPWNhcHRpdmVmcywiCgkJLiJtbnRlbnQubW50X2ZzbmFtZT0kaW1hZ2UsbW50ZW50Lm1u
dF90eXBlPWNhcHRpdmUtJGZzbmFtZSwiCSMgRG91YmxlLWRhc2hlcyBmb3JiaWRkZW4uCgkJLiJk
aXJfY2FjaGVfZW50cmllcz0wLCIKCQkuImltYWdlPSRpbWFnZSwiCgkJLmpvaW4oIiwiLEBvcHRf
bHVmcykuIiwiCgkJLiJjYXB0aXZlX29wdGlvbnM9IgoJCQkJLigkZnNuYW1lIGVxICJjZGZzIiA/
ICItLWNkcm9tOy0tcm87IiA6ICItLWRpc2s7LS1ydzsiKQoJCQkJLiItLWxvYWQtbW9kdWxlPSRu
dG9za3JubDstLWZpbGVzeXN0ZW09JGZpbGVzeXN0ZW07IgoJCQkJLiItLXNhbmRib3gtc2VydmVy
PSRjYXB0aXZlX3NhbmRib3hfc2VydmVyX2JpbjsiCgkJCQkuIi0tYnVnLXBhdGhuYW1lPSR2YXJk
aXIvYnVnLSVGVCVULmNhcHRpdmVidWcueG1sLmd6OyIKCQkJCS4iLS1zeXNsb2c7IgoJCQkJLmpv
aW4oIjsiLEBvcHRfY2FwdGl2ZSk7Cgp3YXJuICIkMDogJy1uJyBub3Qgc3VwcG9ydGVkIC0gaWdu
b3JlZCIgaWYgJG5vbXRhYjsKCgojb25seV9pZl9yb290OiBhbGxvd19vdGhlcixkZWZhdWx0X3Bl
cm1pc3Npb25zCm15ICRmdXNlb3B0cz0iLW9hbGxvd19vdGhlcixkZWZhdWx0X3Blcm1pc3Npb25z
LGZzbmFtZT0kaW1hZ2UiOwoKIyBVc2UgIickb28nIiB0byBwZXJtaXQgYW5vdGhlciBleHBhbnNp
b24gYnkgYmFzaCgxKSBkdXJpbmcgbHVmc21udCg4KSBleGVjdXRpb24uCm15IEBhcmd2PSgkbHVm
c2RfYmluLCRvbywkZGlyLCItcyIsJGZ1c2VvcHRzKTsKCnByaW50IFNUREVSUiAiJDA6IEBhcmd2
XG4iIGlmICR2ZXJib3NlOwpleGVjICRsdWZzZF9iaW4gQGFyZ3Y7CmRpZSAiRmFpbGVkIHRvIGV4
ZWN1dGU6IEBhcmd2IjsK
</data>        

          </attachment>
    </bug>

</bugzilla>