Thank you, it works!
I've just recompiled kernel and now / mounted on reiser4 with /tmp in
the same filesystem,
and pam_mktemp works without problems.
-- 
    Sergey.

Vladimir V. Saveliev пишет:

> Hello
>
> sergey ivanov wrote:
>
>> I have not succeeded with integrating reiser4 & pam_mktemp.
>
>
> Would you try the attached patch, please.
>
>>> From one side I recompiled kernel with reiser4 patches modified to
>>
>> return ENOTTY for attempt to deal with attributes, as tmpfs does.
>> Pam_mktemp does not work after this. So I returned to the kernel with
>> original Namesys' patches.
>> Then by my apeal pam_mktemp was modified to recognize ENOSYS the same
>> way it recognizes ENOTTY returned by tmpfs and try to deal without
>> attributes.
>> But this also does not help pam_mktemp to work.
>> So I did the following: rebooted to runlevel 1, and then did
>> # strace -o su.log -fF su - seriv
>> Once with /tmp on tmpfs and once with /tmp on reiser4.
>> And the following catches my attention: while on tmpfs, the lines
>> dealing with attributes looks like the following:
>> ---
>> 2034 mkdir("/tmp/.private", 0711) = 0
>> 2034 lstat64("/tmp/.private", {st_mode=S_IFDIR|0711, st_size=40,
>> ...}) = 0
>>
>> 2034  open("/tmp/.private", O_RDONLY)   = 3
>> 2034  ioctl(3, EXT2_IOC_GETFLAGS, 0xbfb7aab8) = -1 ENOTTY (Inappropriate
>> ioctl for device)
>> 2034  close(3)                          = 0
>> 2034  mkdir("/tmp/.private/seriv", 01700) = 0
>> 2034  open("/tmp/.private/seriv", O_RDONLY) = 3
>> 2034  ioctl(3, EXT2_IOC_GETFLAGS, 0xbfb7aa88) = -1 ENOTTY (Inappropriate
>> ioctl for device)
>> 2034  close(3)                          = 0
>> 2034  chown32("/tmp/.private/seriv", 0, 500) = 0
>> 2034  chmod("/tmp/.private/seriv", 01770) = 0
>> ---
>> But with /tmp on reiser4, they are:
>> ---
>> 1993  mkdir("/tmp/.private", 0711)      = -1 EEXIST (File exists)
>> 1993  lstat64("/tmp/.private", {st_mode=S_IFDIR|0711, st_size=7,
>> ...}) = 0
>> 1993  open("/tmp/.private", O_RDONLY)   = 3
>> 1993  ioctl(3, EXT2_IOC_GETFLAGS, 0xbf9e37f8) = -1 EISDIR (Is a
>> directory)
>> 1993  close(3)                          = 0
>> 1993  mkdir("/tmp/.private/seriv", 01700) = -1 EEXIST (File exists)
>> 1993  open("/tmp/.private/seriv", O_RDONLY) = 3
>> 1993  ioctl(3, EXT2_IOC_GETFLAGS, 0xbf9e37c8) = -1 EISDIR (Is a
>> directory)
>> 1993  close(3)                          = 0
>> 1993  getuid32()                        = 0
>> 1993  write(2, "Account management:- Cannot make"..., 85) = 85
>> ---
>> So it looks like reiser4 tries to be good and answer to ioctl
>> getting/setting attributes "EEXIST" and "EISDIR", and not return
>> error "ENOTTY". This is the reason, why pam_mktemp passes the tests
>> if filesystem support attributes with confidence that reiser4 can do
>> attributes. I think this was the right decision to return fake
>> successes at the beginning of reiser4 development, but now I think
>> reiser4 should behave more strictly and rejects this attribute
>> setting/getting ioctl by ENOTTY codes.
>
>
>------------------------------------------------------------------------
>
> fs/reiser4/plugin/file/file.c |    2 +-
> fs/reiser4/plugin/object.c    |   17 ++++++++++++-----
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
>diff -puN fs/reiser4/plugin/object.c~reiser4-pam_mktemp-fix 
>fs/reiser4/plugin/object.c
>--- linux-2.6.13-rc5-mm1/fs/reiser4/plugin/object.c~reiser4-pam_mktemp-fix     
>2005-08-12 13:42:05.904058842 +0400
>+++ linux-2.6.13-rc5-mm1-vs/fs/reiser4/plugin/object.c 2005-08-12 
>13:46:12.622408259 +0400
>@@ -966,6 +966,13 @@ isdir(void)
> 
> #define eisdir ((void *)isdir)
> 
>+static int
>+notty(void)
>+{
>+      return RETERR(-ENOTTY);
>+}
>+#define enotty ((void *)notty)
>+
> static ssize_t
> perm(void)
> {
>@@ -1243,7 +1250,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
>               .read = eisdir,
>               .write = eisdir,
>               .release = release_dir,
>-              .ioctl = eisdir,
>+              .ioctl = enotty,
>               .mmap = eisdir,
>               .get_block = NULL,
>               .flow_by_inode = NULL,
>@@ -1299,7 +1306,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
>               .read = eperm,
>               .write = eperm,
>               .release = NULL,
>-              .ioctl = eperm,
>+              .ioctl = enotty,
>               .mmap = eperm,
>               .sync = sync_common,
>               .get_block = NULL,
>@@ -1358,7 +1365,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
>               .read = eperm,
>               .write = eperm,
>               .release = NULL,
>-              .ioctl = eperm,
>+              .ioctl = enotty,
>               .mmap = eperm,
>               .sync = sync_common,
>               .get_block = NULL,
>@@ -1413,7 +1420,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
>               .read              = read_pseudo,
>               .write             = write_pseudo,
>               .release           = release_pseudo,
>-              .ioctl             = eperm,
>+              .ioctl             = enotty,
>               .mmap              = eperm,
>               .sync = sync_common,
>               .get_block         = eperm,
>@@ -1470,7 +1477,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
>               .read = read_cryptcompress,
>               .write = write_cryptcompress,
>               .release = NULL,
>-              .ioctl = NULL,
>+              .ioctl = enotty,
>               .mmap = mmap_cryptcompress,
>               .get_block = get_block_cryptcompress,
>               .sync = sync_common,
>diff -puN fs/reiser4/plugin/file/file.c~reiser4-pam_mktemp-fix 
>fs/reiser4/plugin/file/file.c
>--- linux-2.6.13-rc5-mm1/fs/reiser4/plugin/file/file.c~reiser4-pam_mktemp-fix  
>2005-08-12 13:45:48.276202815 +0400
>+++ linux-2.6.13-rc5-mm1-vs/fs/reiser4/plugin/file/file.c      2005-08-12 
>13:45:58.469126159 +0400
>@@ -2361,7 +2361,7 @@ ioctl_unix_file(struct inode *inode, str
>               break;
> 
>       default:
>-              result = RETERR(-ENOSYS);
>+              result = RETERR(-ENOTTY);
>               break;
>       }
>       return result;
>
>_
>  
>

Reply via email to