* Redundant syscalls?
@ 2002-02-15 16:24 Lorenzo Allegrucci
2002-02-15 17:00 ` Doug McNaught
2002-02-15 18:17 ` Jesse Pollard
0 siblings, 2 replies; 4+ messages in thread
From: Lorenzo Allegrucci @ 2002-02-15 16:24 UTC (permalink / raw)
To: linux-kernel
I was wondering why do we need fsetxattr(2), fgetxattr(2) etc when we
already have setxattr(2), getxattr(2) etc working on file names
instead of file descriptors.
truncate(2)/ftruncate(2) is another more traditional example.
Thanks
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Redundant syscalls?
2002-02-15 16:24 Redundant syscalls? Lorenzo Allegrucci
@ 2002-02-15 17:00 ` Doug McNaught
2002-02-15 18:17 ` Jesse Pollard
1 sibling, 0 replies; 4+ messages in thread
From: Doug McNaught @ 2002-02-15 17:00 UTC (permalink / raw)
To: Lorenzo Allegrucci; +Cc: linux-kernel
Lorenzo Allegrucci <l.allegrucci@tiscalinet.it> writes:
> I was wondering why do we need fsetxattr(2), fgetxattr(2) etc when we
> already have setxattr(2), getxattr(2) etc working on file names
> instead of file descriptors.
> truncate(2)/ftruncate(2) is another more traditional example.
Because you can't reliably derive a file name from an open file
descriptor, so it's useful to have a way to act on the file directly
through the descriptor.
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Redundant syscalls?
2002-02-15 16:24 Redundant syscalls? Lorenzo Allegrucci
2002-02-15 17:00 ` Doug McNaught
@ 2002-02-15 18:17 ` Jesse Pollard
1 sibling, 0 replies; 4+ messages in thread
From: Jesse Pollard @ 2002-02-15 18:17 UTC (permalink / raw)
To: l.allegrucci, linux-kernel
--------- Received message begins Here ---------
>
>
> I was wondering why do we need fsetxattr(2), fgetxattr(2) etc when we
> already have setxattr(2), getxattr(2) etc working on file names
> instead of file descriptors.
> truncate(2)/ftruncate(2) is another more traditional example.
Atomic actions.
Consider the case of a file that doesn't exist yet. first you
open it, then perform the fsetxattr. If you use the name, then it becomes
possible to rename the file and substitute a different one before the
setxattr. Now, the open file will be missing the attribute(s).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <02021517152700.01701@odyssey.suse.lists.linux.kernel>]
* Re: Redundant syscalls?
[not found] <02021517152700.01701@odyssey.suse.lists.linux.kernel>
@ 2002-02-15 17:47 ` Andi Kleen
0 siblings, 0 replies; 4+ messages in thread
From: Andi Kleen @ 2002-02-15 17:47 UTC (permalink / raw)
To: Lorenzo Allegrucci; +Cc: linux-kernel
Lorenzo Allegrucci <l.allegrucci@tiscalinet.it> writes:
> I was wondering why do we need fsetxattr(2), fgetxattr(2) etc when we
> already have setxattr(2), getxattr(2) etc working on file names
> instead of file descriptors.
> truncate(2)/ftruncate(2) is another more traditional example.
The f* variant can be race free. For example you want to stat something
first to make sure it is what you expect it to be and not a symlink
to your /etc/passwd. When you use first stat() and then do random
operation on filename with name there is a small window where someone
could replace the name with something else. This could be security relevant.
fd = open(name, ...); fstat(fd, ..); check fsomething(fd, ...); close(fd);
guarantees that you're always working on the same object without any race
windows.
-Andi
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-02-15 18:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-02-15 16:24 Redundant syscalls? Lorenzo Allegrucci
2002-02-15 17:00 ` Doug McNaught
2002-02-15 18:17 ` Jesse Pollard
[not found] <02021517152700.01701@odyssey.suse.lists.linux.kernel>
2002-02-15 17:47 ` Andi Kleen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.