In the general vein of avoiding security holes by using file
descriptors when doing repeated operations on the same filesystem
object, I have noticed that there doesn't seem to be a way to set
mtime using a file descriptor. Do we need a futimes() syscall?
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
"H. Peter Anvin" wrote:
>
> In the general vein of avoiding security holes by using file
> descriptors when doing repeated operations on the same filesystem
> object, I have noticed that there doesn't seem to be a way to set
> mtime using a file descriptor. Do we need a futimes() syscall?
Parallel to that, there is the long time needed lutimes() syscall.
Who has never been annoyed that restoring a backup there's no way to
restore former symlink mtime?
--
Abramo Bagnara mailto:[email protected]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
H. Peter Anvin, Sun, Feb 02, 2003 02:53:22 +0100:
> In the general vein of avoiding security holes by using file
> descriptors when doing repeated operations on the same filesystem
> object, I have noticed that there doesn't seem to be a way to set
> mtime using a file descriptor. Do we need a futimes() syscall?
There is a small problem with close(). It can update mtime as well.
>Abramo Bagnara wrote:
>"H. Peter Anvin" wrote:
>>
>> In the general vein of avoiding security holes by using file
>> descriptors when doing repeated operations on the same filesystem
>> object, I have noticed that there doesn't seem to be a way to set
>> mtime using a file descriptor. Do we need a futimes() syscall?
>
>Parallel to that, there is the long time needed lutimes() syscall.
>
>Who has never been annoyed that restoring a backup there's no way to
>restore former symlink mtime?
I wonder if we could have an open flags similar to O_NOFOLLOW
that would allow a symbolic link to be "opened" just so it could
be referred to by f{stat,chown,chmod} so that programs that use this
style handle symbolic links the same way.
Also, if you want to add another system call for setting stat
information, perhaps we could take the opportunity to reduce the
number of system calls per file being restored by programs like tar by
creating an fsetstat() system call that would take some kind of
extensible flags field so that programs like tar could do their
business in a single system call. The kernel already seems to do this
internally through inode_operations.setattr. (sys_chown -->
chown_common --> notify_change --> inode_setattr). That way it
would be less likely that we'd have to add a new system calls again
if people think of new file attributes.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
Followup to: <[email protected]>
By author: Alex Riesen <[email protected]>
In newsgroup: linux.dev.kernel
>
> H. Peter Anvin, Sun, Feb 02, 2003 02:53:22 +0100:
> > In the general vein of avoiding security holes by using file
> > descriptors when doing repeated operations on the same filesystem
> > object, I have noticed that there doesn't seem to be a way to set
> > mtime using a file descriptor. Do we need a futimes() syscall?
>
> There is a small problem with close(). It can update mtime as well.
>
Presumably it shouldn't unless the file descriptor has been written
to since the last fsync().
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64