2015-12-22 12:55:44 +01:00
|
|
|
/*
|
2016-12-26 00:35:40 +01:00
|
|
|
* This file is part of Jehanne.
|
|
|
|
*
|
2017-08-25 23:43:14 +02:00
|
|
|
* Copyright (C) 2016-2017 Giacomo Tesio <giacomo@tesio.it>
|
2016-12-26 00:35:40 +01:00
|
|
|
*
|
|
|
|
* Jehanne is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation, version 2 of the License.
|
|
|
|
*
|
|
|
|
* Jehanne is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with Jehanne. If not, see <http://www.gnu.org/licenses/>.
|
2015-12-22 12:55:44 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <u.h>
|
|
|
|
#include <libc.h>
|
|
|
|
|
|
|
|
int
|
2017-04-19 23:33:14 +02:00
|
|
|
jehanne_access(const char *name, int mode)
|
2015-12-22 12:55:44 +01:00
|
|
|
{
|
libc: simplify access; libposix: let access lie
There are a few issues with Plan 9's `access`:
- it has side effects: to test the actual access (that the file
servers can allow or deny according to complex custom rules)
it opens and then closes the file, allocating (and disposing) the fd
- it does not work on directories, since
- they cannot be opened for writing, despite the fact that to
create a file in a directory you must be granted write access on
that directory
- they cannot be opened for execution, despite the fact that to
access a file in a directory you must be granted execution access
on that directory
Despite the fact that `access` (even on UNIX) is a violation of the
"tell, don't ask" principle (the access could be forbidden just after
its successful return, making subsequent `open` fail anyway), this
fact smells of a little design error in the file interface.
So, right now we choose to let the libposix's `access` lie on directories:
it will always return 0 on AWRITE and AEXEC for them, accepting that
a successive create/mkdir may fail.
However, a cleaner file API and protocol should allow a simpler `access`
to be implemented for directories too.
2017-08-29 00:17:51 +02:00
|
|
|
int fd, reqmode;
|
2016-12-24 21:25:20 +01:00
|
|
|
|
|
|
|
static char omode[] = {
|
2016-12-26 00:35:40 +01:00
|
|
|
OSTAT,
|
2016-12-24 21:25:20 +01:00
|
|
|
OEXEC,
|
|
|
|
OWRITE,
|
|
|
|
ORDWR,
|
|
|
|
OREAD,
|
2016-12-26 00:35:40 +01:00
|
|
|
OEXEC, /* 5=4+1 READ|EXEC, EXEC is enough */
|
2016-12-24 21:25:20 +01:00
|
|
|
ORDWR,
|
2016-12-26 00:35:40 +01:00
|
|
|
ORDWR /* 7=4+2+1 READ|WRITE|EXEC, ignore EXEC */
|
2016-12-24 21:25:20 +01:00
|
|
|
};
|
2015-12-22 12:55:44 +01:00
|
|
|
|
2017-08-28 02:09:56 +02:00
|
|
|
reqmode = omode[mode&AMASK];
|
libc: simplify access; libposix: let access lie
There are a few issues with Plan 9's `access`:
- it has side effects: to test the actual access (that the file
servers can allow or deny according to complex custom rules)
it opens and then closes the file, allocating (and disposing) the fd
- it does not work on directories, since
- they cannot be opened for writing, despite the fact that to
create a file in a directory you must be granted write access on
that directory
- they cannot be opened for execution, despite the fact that to
access a file in a directory you must be granted execution access
on that directory
Despite the fact that `access` (even on UNIX) is a violation of the
"tell, don't ask" principle (the access could be forbidden just after
its successful return, making subsequent `open` fail anyway), this
fact smells of a little design error in the file interface.
So, right now we choose to let the libposix's `access` lie on directories:
it will always return 0 on AWRITE and AEXEC for them, accepting that
a successive create/mkdir may fail.
However, a cleaner file API and protocol should allow a simpler `access`
to be implemented for directories too.
2017-08-29 00:17:51 +02:00
|
|
|
fd = open(name, reqmode);
|
|
|
|
if(fd >= 0){
|
|
|
|
close(fd);
|
2015-12-22 12:55:44 +01:00
|
|
|
return 0;
|
|
|
|
}
|
libc: simplify access; libposix: let access lie
There are a few issues with Plan 9's `access`:
- it has side effects: to test the actual access (that the file
servers can allow or deny according to complex custom rules)
it opens and then closes the file, allocating (and disposing) the fd
- it does not work on directories, since
- they cannot be opened for writing, despite the fact that to
create a file in a directory you must be granted write access on
that directory
- they cannot be opened for execution, despite the fact that to
access a file in a directory you must be granted execution access
on that directory
Despite the fact that `access` (even on UNIX) is a violation of the
"tell, don't ask" principle (the access could be forbidden just after
its successful return, making subsequent `open` fail anyway), this
fact smells of a little design error in the file interface.
So, right now we choose to let the libposix's `access` lie on directories:
it will always return 0 on AWRITE and AEXEC for them, accepting that
a successive create/mkdir may fail.
However, a cleaner file API and protocol should allow a simpler `access`
to be implemented for directories too.
2017-08-29 00:17:51 +02:00
|
|
|
|
|
|
|
/* WARNING:
|
|
|
|
*
|
|
|
|
* In Plan 9 access(AWRITE) and access(AEXEC) in directories
|
|
|
|
* fail despite the actual permission of the directory.
|
|
|
|
*
|
|
|
|
* This is well understood in Plan 9, but it's counter intuitive.
|
|
|
|
*
|
|
|
|
* In Plan 9, to create a file in a directory you need write
|
|
|
|
* permission in the directory. Still you don't need to (and you
|
|
|
|
* cannot) open the directory for writing before calling create.
|
|
|
|
*
|
|
|
|
* To my eyes this is a UNIX inheritance that could be "fixed"
|
|
|
|
* but there are some trade off.
|
|
|
|
*/
|
2015-12-22 12:55:44 +01:00
|
|
|
return -1;
|
|
|
|
}
|