*at syscalls for xattrs?

*at syscalls for xattrs?

[Jan Engelhardt]

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
-- 

Re: *at syscalls for xattrs?

[Al Viro]

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?

Re: *at syscalls for xattrs?

[Nicholas Miell]

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 <nmiell@comcast.net>

Re: *at syscalls for xattrs?

[Al Viro]

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"

Re: *at syscalls for xattrs?

[H. Peter Anvin]

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

Re: *at syscalls for xattrs?

[Jan Engelhardt]

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
-- 

Re: *at syscalls for xattrs?

[Al Viro]

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...

Re: *at syscalls for xattrs?

[Jeremy Fitzhardinge]

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

Re: *at syscalls for xattrs?

[Miklos Szeredi]

> > 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

Re: *at syscalls for xattrs?

[Andreas Schwab]

Jeremy Fitzhardinge <jeremy@goop.org> 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, schwab@suse.de
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: *at syscalls for xattrs?

[H. Peter Anvin]

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

Re: *at syscalls for xattrs?

[Jeff Garzik]

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

Re: *at syscalls for xattrs?

[H. Peter Anvin]

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

Re: *at syscalls for xattrs?

[Jeff Garzik]

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

Re: *at syscalls for xattrs?

[H. Peter Anvin]

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