Re: *at syscalls for xattrs?
Jeff Garzik wrote: >> >> Well, as Jeremy pointed out, in the absence of threads you can do the >> same thing with fchdir(), however, that's much more of a hack. > > My posixutils project (coreutils replacement) used fchdir(2), but that > still doesn't get you 100% race-free. It gets you close, yes. > I guess you're horked in the case where a single system call (e.g. rename()) needs more than one pathname. Yet another reason why a single cwd isn't enough. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
H. Peter Anvin wrote: Jeff Garzik wrote: What the *at() interfaces really do is fix/paper over a longstanding wart in Unix: the cwd really should have been a standard file descriptor (like stdin/stdout/stderr) instead of a magic piece of state maintained in kernel space. It's more than a wart, IMO. *at() allows one to close races (with potential security implications) that are otherwise impossible to close, in directory traversal. *at() permits a userspace program to hold proper references to all objects during a directory traversal, with all that implies. Well, as Jeremy pointed out, in the absence of threads you can do the same thing with fchdir(), however, that's much more of a hack. My posixutils project (coreutils replacement) used fchdir(2), but that still doesn't get you 100% race-free. It gets you close, yes. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
Jeff Garzik wrote: >> >> What the *at() interfaces really do is fix/paper over a longstanding >> wart in Unix: the cwd really should have been a standard file descriptor >> (like stdin/stdout/stderr) instead of a magic piece of state maintained >> in kernel space. > > It's more than a wart, IMO. *at() allows one to close races (with > potential security implications) that are otherwise impossible to close, > in directory traversal. > > *at() permits a userspace program to hold proper references to all > objects during a directory traversal, with all that implies. > Well, as Jeremy pointed out, in the absence of threads you can do the same thing with fchdir(), however, that's much more of a hack. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
H. Peter Anvin wrote: Miklos Szeredi wrote: The *at() thing basically gives you the advantages of a CWD without the disadvantages. For example it could be useful to implement the functionality of find(1) as a library interface. What the *at() interfaces really do is fix/paper over a longstanding wart in Unix: the cwd really should have been a standard file descriptor (like stdin/stdout/stderr) instead of a magic piece of state maintained in kernel space. It's more than a wart, IMO. *at() allows one to close races (with potential security implications) that are otherwise impossible to close, in directory traversal. *at() permits a userspace program to hold proper references to all objects during a directory traversal, with all that implies. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
Miklos Szeredi wrote: > > The *at() thing basically gives you the advantages of a CWD without > the disadvantages. > > For example it could be useful to implement the functionality of > find(1) as a library interface. > What the *at() interfaces really do is fix/paper over a longstanding wart in Unix: the cwd really should have been a standard file descriptor (like stdin/stdout/stderr) instead of a magic piece of state maintained in kernel space. If they had been designed-in from the beginning I suspect we wouldn't have had, say, stat() and fstat(), but simply statat() -- the "normal" ones would simply be statat(stddir, path) and statat(fd, NULL) respectively. Now it isn't quite so clean. You can do some of that stuff with fchdir(), but *at() is much nicer, minus the oddball Solaris naming with random presence and absence of f- prefixes. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> This should work:
>
>fchdir(fd1);
>open("file1", O_RDWR | O_CREAT);
>fchdir(fd2);
>open("file2", O_RDWR | O_CREAT);
This is not thread-safe.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
> > fd1 = open("dir1", O_DIRECTORY):
> > fd2 = open("dir2", O_DIRECTORY);
> > system("mount -t tmpfs none dir1");
> > system("mount -t tmpfs none dir2");
> > openat(fd1, "file1", O_RDWR | O_CREAT);
> > openat(fd2, "file2", O_RDWR | O_CREAT);
> > If you have a better way to accomplish this, let me know. :)
> >
>
> This should work:
>
> fchdir(fd1);
> open("file1", O_RDWR | O_CREAT);
> fchdir(fd2);
> open("file2", O_RDWR | O_CREAT);
If you only have a single thread, yes.
The *at() thing basically gives you the advantages of a CWD without
the disadvantages.
For example it could be useful to implement the functionality of
find(1) as a library interface.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
Jan Engelhardt wrote:
fd1 = open("dir1", O_DIRECTORY):
fd2 = open("dir2", O_DIRECTORY);
system("mount -t tmpfs none dir1");
system("mount -t tmpfs none dir2");
openat(fd1, "file1", O_RDWR | O_CREAT);
openat(fd2, "file2", O_RDWR | O_CREAT);
If you have a better way to accomplish this, let me know. :)
This should work:
fchdir(fd1);
open("file1", O_RDWR | O_CREAT);
fchdir(fd2);
open("file2", O_RDWR | O_CREAT);
J
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
On Mon, Jul 16, 2007 at 09:56:10AM +0200, Jan Engelhardt wrote:
> >Just one question: what the bleeding hell for? Not that the rest of
> >..at() family made any damn sense as an interface...
>
> fd1 = open("dir1", O_DIRECTORY):
> fd2 = open("dir2", O_DIRECTORY);
> system("mount -t tmpfs none dir1");
> system("mount -t tmpfs none dir2");
> openat(fd1, "file1", O_RDWR | O_CREAT);
> openat(fd2, "file2", O_RDWR | O_CREAT);
>
> If you have a better way to accomplish this, let me know. :)
To accomplish what, exactly? Access to overmounted directory?
So bind it elsewhere and use that. I still don't see the point -
neither of the interface nor of your example...
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
On Jul 15 2007 23:23, Al Viro wrote:
>On Sun, Jul 15, 2007 at 02:13:21PM -0700, Nicholas Miell wrote:
>>
>> I suspect he was asking for
>>
>> int getxattrat(int fd, const char *path, const char *name, void *value,
>> size_t size, int flags)
>> int setxattrat(int fd, const char *path, const char *name, void *value,
>> size_t size, int xattrflags, int atflags)
>>
>> rather than the ability to access xattrs as files.
>
>Just one question: what the bleeding hell for? Not that the rest of
>..at() family made any damn sense as an interface...
fd1 = open("dir1", O_DIRECTORY):
fd2 = open("dir2", O_DIRECTORY);
system("mount -t tmpfs none dir1");
system("mount -t tmpfs none dir2");
openat(fd1, "file1", O_RDWR | O_CREAT);
openat(fd2, "file2", O_RDWR | O_CREAT);
If you have a better way to accomplish this, let me know. :)
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
Al Viro wrote: > BTW, why is fstatat called fstatat and not statat? (Same goes for futimesat.) It does not take a file descriptor for the file argument. Otherwise we'd also need fopenat/funlinkat, etc. Any reasons? >>> Ulrich having an odd taste? >> Solaris compatibility. > > "Sun having no taste whatsoever" Yup. I filed an objection to this with the POSIX committee, but it was rejected :( -hpa - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
On Sun, Jul 15, 2007 at 02:13:21PM -0700, Nicholas Miell wrote: > > I suspect he was asking for > > int getxattrat(int fd, const char *path, const char *name, void *value, > size_t size, int flags) > int setxattrat(int fd, const char *path, const char *name, void *value, > size_t size, int xattrflags, int atflags) > > rather than the ability to access xattrs as files. Just one question: what the bleeding hell for? Not that the rest of ..at() family made any damn sense as an interface... > > > BTW, why is fstatat called fstatat and not statat? (Same goes for > > > futimesat.) It does not take a file descriptor for the file argument. > > > Otherwise we'd also need fopenat/funlinkat, etc. Any reasons? > > > > Ulrich having an odd taste? > > Solaris compatibility. "Sun having no taste whatsoever" - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
On Sun, 2007-07-15 at 21:53 +0100, Al Viro wrote: > On Sun, Jul 15, 2007 at 09:46:27PM +0200, Jan Engelhardt wrote: > > Hi, > > > > > > recently, the family of *at() syscalls and functions (openat, fstatat, > > etc.) have been added to Linux and Glibc, respectively. > > In short: I am missing xattr at functions :) > > No. They are not fscking forks. They are almost as revolting, but > not quite on the same level. I suspect he was asking for int getxattrat(int fd, const char *path, const char *name, void *value, size_t size, int flags) int setxattrat(int fd, const char *path, const char *name, void *value, size_t size, int xattrflags, int atflags) rather than the ability to access xattrs as files. > > BTW, why is fstatat called fstatat and not statat? (Same goes for > > futimesat.) It does not take a file descriptor for the file argument. > > Otherwise we'd also need fopenat/funlinkat, etc. Any reasons? > > Ulrich having an odd taste? Solaris compatibility. -- Nicholas Miell <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: *at syscalls for xattrs?
On Sun, Jul 15, 2007 at 09:46:27PM +0200, Jan Engelhardt wrote: > Hi, > > > recently, the family of *at() syscalls and functions (openat, fstatat, > etc.) have been added to Linux and Glibc, respectively. > In short: I am missing xattr at functions :) No. They are not fscking forks. They are almost as revolting, but not quite on the same level. > BTW, why is fstatat called fstatat and not statat? (Same goes for > futimesat.) It does not take a file descriptor for the file argument. > Otherwise we'd also need fopenat/funlinkat, etc. Any reasons? Ulrich having an odd taste? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
*at syscalls for xattrs?
Hi, recently, the family of *at() syscalls and functions (openat, fstatat, etc.) have been added to Linux and Glibc, respectively. In short: I am missing xattr at functions :) BTW, why is fstatat called fstatat and not statat? (Same goes for futimesat.) It does not take a file descriptor for the file argument. Otherwise we'd also need fopenat/funlinkat, etc. Any reasons? Thanks, Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
