Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Archives randomly expanded with owner as root #38

Closed
hasse69 opened this issue Mar 13, 2015 · 12 comments
Closed

Archives randomly expanded with owner as root #38

hasse69 opened this issue Mar 13, 2015 · 12 comments

Comments

@hasse69
Copy link
Owner

hasse69 commented Mar 13, 2015

rar2fs on /mnt/BackupU type fuse.rar2fs (ro,nosuid,nodev,allow_other,default_permissions)


Any tips would be appreciated. Archive attributes on file are -rw-r-----
Details: RAR 4, volume

Attributes on a working dir (mounted as the parent user) are -rw-rw-rw-.

Original issue reported on code.google.com by kyle.leet on 2015-02-09

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

Thanks for the issue report.

Would it be possible to provide a bit more details about the problem you experience?
According to the subject it has something to do with root ownership but in the detailed
description you only mention access mode flags.
Is it the actual mounted folder that you see issues with? Do you mount an archive directly
or a folder containing several archives?
If it is a single RAR archive that you mount, eg. test.rar -> my_folder, did you expect
my_folder to obtain the same access permission as the file test.rar?

Original issue reported on code.google.com by hasse69 on 2015-02-10 17:54:43

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

I have a parent folder that contains a number of archives underneath child folders.
This parent is mounted against rar2fs. From there, the archives typically contain an
mkv, mp4, jpg, or something else. The extracted virtual file is the one that has wonky
permissions, usually with the owner not being the parent folder, and the extracted
file is owned by root with 640 typically.

And yes, I would expect my_folder to have the same permissions and groups.

Original issue reported on code.google.com by kyle.leet on 2015-02-10 18:03:43

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

Alright. Regarding the parent folder permission and mount point I have verified that
they become the same. Is that not the case for you?
Also, are you saying that files get uid set root? That sounds really strange because
all the virtual files obtain gid/uid from getgid()getuid() which should equal the user
that mounted the file system. Regarding access permission they are directly taken from
the archive and then umask is applied. This is if the archive was created in UNIX mode.
If it is in DOS mode the access permission for files are set to 0666 and 0777 respectively
and then umask is applied. I would not say that that is a random behavior but of course
there is a difference between UNIX and DOS mode archives since the latter does not
provide the proper information.  

Original issue reported on code.google.com by hasse69 on 2015-02-11 11:00:56

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

I think I've figured it out. Permissions are taken from the archived file, I did not
expect this at all. Most files that I'm opening are set to 666, however a couple few
contain 640 that I was seeing as rar2fs being completely broken. Any idea if it's possible
to force the permissions, or to take the actual local file permissions for the archive?
I don't really care what permissions the actual archived file had when people had sent
it over. I'm not sure in which scenario I would like this to be the preference.


-rw-rw-rw- 1 root root

Much thanks so far for the help, and trying to figure out what was going wrong :-)

Original issue reported on code.google.com by kyle.leet on 2015-02-11 21:06:11

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

Exactly. That was what I was trying to say that the permission are taken from the archived
files after applying your umask. rar2fs tries to make an exact mimic of the RAR file
contents. Try this exercise, unrar one of the archives in a destination folder of choice,
what will be the result? My guess is that you will obtain the same permission flags
as you would in a rar2fs mount point. Or?
If that is not the case then I need to look into it of course.
You can control the umask itself. Either by setting it in your environment or by adding
it as a mount option to rar2fs.

Original issue reported on code.google.com by hasse69 on 2015-02-11 21:33:57

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

The glitch is, when I extract the archive owned by 'Lenny'. Lenny becomes the owner.
When rar2fs does it, root is the owner because that's how it's running, presumably.

But no, you're right, when I `unrar x *.rar` the permissions are indeed 640, which
is absolutely tragic. Ignorance is bliss when you're the owner of the file :-)

Is there any way to grab the actual permissions from the .rar file itself, instead
of the sub-folders? Baring execute, it would be most likely what is desired.

Original issue reported on code.google.com by kyle.leet on 2015-02-11 21:43:15

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

s/sub-folders/archived files/

Original issue reported on code.google.com by kyle.leet on 2015-02-11 21:44:04

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

Then why do you not simply mount as 'Lenny' then? You do not need to be root to use
fuse. And as I said, fuse as an option to set the umask. It works a little bit different
though compared to how umask is applied from the environment which is masked with the
default 0666/0777 depending on file type. The fuse option always seem to originate
from 0777 and then applies the provided umask, irrespective of if it is a file or folder.
So to set all flags, always, on all file types use '-o umask=0000' as an extra option
to the rar2fs command line.

Original issue reported on code.google.com by hasse69 on 2015-02-11 22:03:25

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

And btw, RAR is an archiver among many others, but common is that they usually tend
to maintain the file properties including permission because that is what the creator
of archives usually wish them to do. Right ;)

Original issue reported on code.google.com by hasse69 on 2015-02-11 22:07:36

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

You can also use the mount option '-o uid=Lenny' to force Lenny to become the owner
of all files (as if Lenny was the user extracting the archives).
And of course '-o gid' cab be used in a similar fashion.

From the fuse manual:

umask=M

  Override the permission bits in 'st_mode' set by the filesystem.
  The resulting permission bits are the ones missing from the given
  umask value.  The value is given in octal representation.

uid=N

  Override the 'st_uid' field set by the filesystem.

gid=N

  Override the 'st_gid' field set by the filesystem.

Original issue reported on code.google.com by hasse69 on 2015-02-11 22:19:08

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

I'm using /etc/fstab, I don't know how to mount as a specific user. Looking at the FAQ
after that comment I think I understand what you're saying, I should also use uid to
mount as Lenny ;)

Definitely the sledgehammer approach with umask, but that's what is desired on my end
:-). The filesystem is read only, so I don't really care.

Thanks a ton! I don't think I can close issues, sorry. RESOLVED INVALID :-)

Original issue reported on code.google.com by kyle.leet on 2015-02-11 22:19:42

@hasse69
Copy link
Owner Author

hasse69 commented Apr 29, 2015

No problem. And again, thanks for the issue report. But since fuse has built-in support
to override file system defaults I do not wish to clutter rar2fs with more functionality
that is not actually needed.

Have fun with your archives whatever permission they might get! :)

Case closed.

Original issue reported on code.google.com by hasse69 on 2015-02-11 22:25:59

@hasse69 hasse69 closed this as completed Apr 29, 2015
Repository owner locked and limited conversation to collaborators Apr 29, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant