futimes()?

futimes()?

[H. Peter Anvin]

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

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> 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

Re: futimes()?

[Abramo Bagnara]

"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:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

Re: futimes()?

[Alex Riesen]

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.

Re: futimes()?

[H. Peter Anvin]

Followup to:  <20030202120752.GK5239@riesen-pc.gr05.synopsys.com>
By author:    Alex Riesen <alexander.riesen@synopsys.COM>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> 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

Re: futimes()?

[Adam J. Richter]

>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
adam@yggdrasil.com     \ /                  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."