On Tuesday 15 January 2008, Ilya N. Golubev wrote:
> It is not necessarily bug of util-linux itself. However, since there
> is no other well known tool to make arbitrary `mount' system call, and
> specify to it as many options as `mount' program from util-linux
> allows, this program is the only way to reproduce the failure. And
> even determining that it is something outside `mount' program is
> broken requires full- blown debugging of the program.
not really. use `strace` to examine the actual mount() syscall made, and then
you can trivially write a tiny C program to reproduce the issue:
#include <sys/syscall.h>
int main() { return syscall(SYS_mount, whatever,your,args,are); }
> File system may contain data not to let any logged in user read. Wish
> to specify more restrictive mode of files in it. This certainly must
> occur on mount itself, not in subsequent `chmod' calls. There is at
> least one obvious reason to avoid explicit `chmod', just as many other
> uses of it: possible race condition between it and other process
> opening the file. Seeing no way to have `mount' do that.
the fact that iso9660 is a read-only filesystem seems more important than
any "race conditions". such conditions are trivial to avoid anyways: start
with a root-restricted permission setup at mount, and then grant things after
with chmod.
> When mounting read- only iso9660 file system, `mount' ignores
> `mode=400' file system option. More precisely,
>
> mount -nv -t iso9660 -o ro,norock,mode=400,uid=ID_OF_REGULAR_USER DEVICE
> DIR
please consult the mount man page. it states that mode= is only interpreted
as octal if there is a leading 0.
if things still fail, please execute:
strace -f -emount,execve <whatever mount you're doing>
and then post the output
-mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
