Re: [Dump-users] restore incorrectly changes mode from 0777 to 0700 for the rip rescue distro

[Alan W. I. <ir...@be...>]

On 2004-09-23 07:20+0200 Stelian Pop wrote:

> On Wed, Sep 22, 2004 at 02:02:01PM -0700, Alan W. Irwin wrote:
>
>>> I see that rip exists in linux and BSD versions. You are using the Linux
>>> version, don't you ?
>>
>> Yes.  My latest tests were for RIP-11.0.iso.bin which is the Slackware-based
>> Linux version of RIP with kernel-2.6.8.
>>
>> Additional information is if I try to create symlinks by hand on rip they
>> come out as mode 755.  So it is not the same as the mode 700 created by
>> restore under RIP, but nevertheless it is different from the expected 777
>> (see above).
>
> Perhaps the umask is used ? If you set the umask to 0 do the symlinks
> get created with 0777 ?

It depends....  Here is the story in detail.

I tried changing the RIP umask from the default 0022 to 0000 and and it made
no difference to restore; restore continued to change all symlink
permissions to 0700. I also created a pristine ext3 filesystem (using
'mke2fs -j /dev/hda3' on RIP) which was mounted with 'mount /dev/hda3
/mnt/dum3'.  The results of the subsequent mount command to list out options
for each filesystem were as follows:

tmpfs on / type tmpfs (rw)
/dev/hda3 on /mnt/dum3 type ext3 (rw)

The first one is apparently how RIP creates a root file system in RAM, and
the second one shows no special options for /mnt/dum3

But if I am in the /mnt directory, i.e. in the tmpfs root filesystem, then the
series of commands:

umask 0000
ln -s /tmp/test_0000
umask 0022
ln -s /tmp/test_0022
umask 0077
ln -s /tmp/test_0077
ls -l test*

shows permissions of all links are 0777, but if I do the same series in
/mnt/dum3, i.e., in the ext3 filesystem then test_0000 has permissions of
0777, test_0022 has permissions of 0755, and test_0077 has permissions of
0700.  So the behaviour of symlink permissions depends on the filesystem for
RIP (and possibly Slackware since RIP is based on that).

I could find no option in mke2fs or tune2fs that would affect symlink
permissions.  It seems to me the only possibility left is there is a kernel
compile option or run-time parameter that is affecting the behaviour of
symlink permissions on ext2/3 filesystems.  The trouble is finding what the
option is and learning how to change it so that restore works correctly for
symlinks. Note this apparently only seems to be a problem for RIP and
perhaps other Slackware-based distros.  Debian-testing and knoppix (also
based on Debian) both seem fine.

My RIP, Debian testing, and knoppix testing has all been done for
kernel-2.6.  Does anybody on this list have access to a Slackware kernel-2.6
system to check whether restore is able to create the correct symlink
permissions?

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________