On Fri, 1 Dec 2000, Olivier Galibert wrote:
> On Wed, Nov 29, 2000 at 04:40:29PM +, Tigran Aivazian wrote:
> > b) what should be the return of access(W_OK) (or, the same, open() for
> > write with switched uid) for devices on a readonly-mounted filesystems?
> >
> > Should the majority win?
On Wed, Nov 29, 2000 at 04:40:29PM +, Tigran Aivazian wrote:
> b) what should be the return of access(W_OK) (or, the same, open() for
> write with switched uid) for devices on a readonly-mounted filesystems?
>
> Should the majority win? I.e. should we say OK, as we do now?
My gut feeling
On Wed, Nov 29, 2000 at 04:40:29PM +, Tigran Aivazian wrote:
b) what should be the return of access(W_OK) (or, the same, open() for
write with switched uid) for devices on a readonly-mounted filesystems?
Should the majority win? I.e. should we say OK, as we do now?
My gut feeling on
On Fri, 1 Dec 2000, Olivier Galibert wrote:
On Wed, Nov 29, 2000 at 04:40:29PM +, Tigran Aivazian wrote:
b) what should be the return of access(W_OK) (or, the same, open() for
write with switched uid) for devices on a readonly-mounted filesystems?
Should the majority win? I.e.
From [EMAIL PROTECTED] Wed Nov 29 17:52:57 2000
> Should the majority win? I.e. should we say OK, as we do now?
We should, but we don't. 2.4 does the right thing.
2.2 got the following change back in 2.2.6:
res = PTR_ERR(dentry);
if (!IS_ERR(dentry)) {
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
> On Wed, 29 Nov 2000, Alexander Viro wrote:
> > Considering your previous workplace... How does official SVR{4,5} behave?
>
> Under SCO UnixWare 7.1.1 you can happily write to devices in a readonly
> mounted (vxfs) filesystem. You can also happily
On Wed, 29 Nov 2000, Alexander Viro wrote:
> Considering your previous workplace... How does official SVR{4,5} behave?
Under SCO UnixWare 7.1.1 you can happily write to devices in a readonly
mounted (vxfs) filesystem. You can also happily access(W_OK) them. Just
tried, right now (ok, it should
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
> That is precisely the point I was making in my previous email. But both
> that email and yours asnwer only one question:
>
> a) should access(2) behave identical to open(2) (with switched uid)? The
> answer is Yes.
>
> but the main question still
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
>
> The classical interpretation of the access(2) system call is "do the same
> type of permission check as open(2) would do but using real uid in the
> credentials instead of effective (or on Linux fs) uid".
> All I am saying is that if open on
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
> All I am saying is that if open on HP/UX allows writing but access denies
> it, it is definitely a bug (in HP/UX). Let's remember why access(2) was
> invented at all -- to allow setuid-privileged programs to do permission
> checks based on real uid
On Wed, 29 Nov 2000, Alexander Viro wrote:
> Historically, on systems that allow write access to devices
> on r/o filesystems access() doesn't return EROFS for devices. Moreover, that's
> what one might reasonably expect and there are programs relying on that.
> Principle of minimal surprise and
just to add (obvious!) -- whenever "uid" was mentioned I implied "uid and
gid"...
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
> On Wed, 29 Nov 2000, Hugh Dickins wrote:
> > Sorry, I missed the point at issue here, and what changed when.
> > Assuming (perhaps wrongly) it's independent of
On Wed, 29 Nov 2000, Hugh Dickins wrote:
> Sorry, I missed the point at issue here, and what changed when.
> Assuming (perhaps wrongly) it's independent of filesystem type,
>
> Solaris yes ok ok
> HP-UX yes EROFS ok
>
> I don't
On Wed, 29 Nov 2000, Hugh Dickins wrote:
> Sorry, I missed the point at issue here, and what changed when.
> Assuming (perhaps wrongly) it's independent of filesystem type,
>
> Solaris yes ok ok
> HP-UX yes EROFS ok
>
> I don't
On Wed, 29 Nov 2000, Alexander Viro wrote:
>
> On Wed, 29 Nov 2000, Hugh Dickins wrote:
>
> > Yes, and I think you'll have difficulty, Andries, finding
> > any other Unices which interpret the standard as you and
> > Linux do: Solaris, HP-UX, UnixWare and OpenServer all allow
> > writing to a
On Wed, 29 Nov 2000, Hugh Dickins wrote:
> On Tue, 28 Nov 2000, Andries Brouwer wrote:
> > On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
> >
> > > Ok, so if you read the standard carefully you get a bogus result.
> >
> > Why bogus? Things could have been otherwise, but the
On Wed, 29 Nov 2000, Hugh Dickins wrote:
> On Tue, 28 Nov 2000, Andries Brouwer wrote:
> > On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
> >
> > > Ok, so if you read the standard carefully you get a bogus result.
> >
> > Why bogus? Things could have been otherwise, but the
On Tue, 28 Nov 2000, Andries Brouwer wrote:
> On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
>
> > Ok, so if you read the standard carefully you get a bogus result.
>
> Why bogus? Things could have been otherwise, but the important
> part is that all Unices do things the same
On Tue, 28 Nov 2000, Andries Brouwer wrote:
On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
Ok, so if you read the standard carefully you get a bogus result.
Why bogus? Things could have been otherwise, but the important
part is that all Unices do things the same way.
On Wed, 29 Nov 2000, Hugh Dickins wrote:
On Tue, 28 Nov 2000, Andries Brouwer wrote:
On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
Ok, so if you read the standard carefully you get a bogus result.
Why bogus? Things could have been otherwise, but the important
On Wed, 29 Nov 2000, Hugh Dickins wrote:
On Tue, 28 Nov 2000, Andries Brouwer wrote:
On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
Ok, so if you read the standard carefully you get a bogus result.
Why bogus? Things could have been otherwise, but the important
On Wed, 29 Nov 2000, Alexander Viro wrote:
On Wed, 29 Nov 2000, Hugh Dickins wrote:
Yes, and I think you'll have difficulty, Andries, finding
any other Unices which interpret the standard as you and
Linux do: Solaris, HP-UX, UnixWare and OpenServer all allow
writing to a device node
On Wed, 29 Nov 2000, Hugh Dickins wrote:
Sorry, I missed the point at issue here, and what changed when.
Assuming (perhaps wrongly) it's independent of filesystem type,
Solaris yes ok ok
HP-UX yes EROFS ok
I don't have
On Wed, 29 Nov 2000, Hugh Dickins wrote:
Sorry, I missed the point at issue here, and what changed when.
Assuming (perhaps wrongly) it's independent of filesystem type,
Solaris yes ok ok
HP-UX yes EROFS ok
I don't have
just to add (obvious!) -- whenever "uid" was mentioned I implied "uid and
gid"...
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
On Wed, 29 Nov 2000, Hugh Dickins wrote:
Sorry, I missed the point at issue here, and what changed when.
Assuming (perhaps wrongly) it's independent of filesystem
On Wed, 29 Nov 2000, Alexander Viro wrote:
Historically, on systems that allow write access to devices
on r/o filesystems access() doesn't return EROFS for devices. Moreover, that's
what one might reasonably expect and there are programs relying on that.
Principle of minimal surprise and all
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
All I am saying is that if open on HP/UX allows writing but access denies
it, it is definitely a bug (in HP/UX). Let's remember why access(2) was
invented at all -- to allow setuid-privileged programs to do permission
checks based on real uid
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
The classical interpretation of the access(2) system call is "do the same
type of permission check as open(2) would do but using real uid in the
credentials instead of effective (or on Linux fs) uid".
All I am saying is that if open on HP/UX
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
That is precisely the point I was making in my previous email. But both
that email and yours asnwer only one question:
a) should access(2) behave identical to open(2) (with switched uid)? The
answer is Yes.
but the main question still
On Wed, 29 Nov 2000, Alexander Viro wrote:
Considering your previous workplace... How does official SVR{4,5} behave?
Under SCO UnixWare 7.1.1 you can happily write to devices in a readonly
mounted (vxfs) filesystem. You can also happily access(W_OK) them. Just
tried, right now (ok, it should
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
On Wed, 29 Nov 2000, Alexander Viro wrote:
Considering your previous workplace... How does official SVR{4,5} behave?
Under SCO UnixWare 7.1.1 you can happily write to devices in a readonly
mounted (vxfs) filesystem. You can also happily
From [EMAIL PROTECTED] Wed Nov 29 17:52:57 2000
Should the majority win? I.e. should we say OK, as we do now?
We should, but we don't. 2.4 does the right thing.
2.2 got the following change back in 2.2.6:
res = PTR_ERR(dentry);
if (!IS_ERR(dentry)) {
On Tue, 28 Nov 2000, Peter Cordes wrote:
> I'm of the opinion that Linux should work in the way that is most useful,
> as long as that doesn't stop us from running stuff written for other unices.
> Unix is mostly good, but parts of it suck. There's no reason to keep the
> parts that suck,
On Mon, Nov 27, 2000 at 01:42:51PM +0100, Andries Brouwer wrote:
> On Sun, Nov 26, 2000 at 11:35:22PM -0400, Peter Cordes wrote:
>
> > While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
> > that open(1) doesn't work when / is mounted read only.
>
> Already long ago
On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
> Ok, so if you read the standard carefully you get a bogus result.
Why bogus? Things could have been otherwise, but the important
part is that all Unices do things the same way.
> Question: Was it meant this way, or did someone
Andries Brouwer wrote:
> On Mon, Nov 27, 2000 at 10:47:06PM +0100, Rogier Wolff wrote:
> > Andries Brouwer wrote:
> > > > access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
> >
> > > You misunderstand the function of access(). The standard says
> > >
> > > [EROFS] write
Andries Brouwer wrote:
On Mon, Nov 27, 2000 at 10:47:06PM +0100, Rogier Wolff wrote:
Andries Brouwer wrote:
access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
You misunderstand the function of access(). The standard says
[EROFS] write access shall fail
On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
Ok, so if you read the standard carefully you get a bogus result.
Why bogus? Things could have been otherwise, but the important
part is that all Unices do things the same way.
Question: Was it meant this way, or did someone just
On Mon, Nov 27, 2000 at 01:42:51PM +0100, Andries Brouwer wrote:
On Sun, Nov 26, 2000 at 11:35:22PM -0400, Peter Cordes wrote:
While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
that open(1) doesn't work when / is mounted read only.
Already long ago open(1) was
On Tue, 28 Nov 2000, Peter Cordes wrote:
I'm of the opinion that Linux should work in the way that is most useful,
as long as that doesn't stop us from running stuff written for other unices.
Unix is mostly good, but parts of it suck. There's no reason to keep the
parts that suck, except
On Mon, Nov 27, 2000 at 10:47:06PM +0100, Rogier Wolff wrote:
> Andries Brouwer wrote:
> > > access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
>
> > You misunderstand the function of access(). The standard says
> >
> > [EROFS] write access shall fail if write access is
Andries Brouwer wrote:
> > access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
> You misunderstand the function of access(). The standard says
>
> [EROFS] write access shall fail if write access is requested
> for a file on a read-only file system
The intent of
On Sun, Nov 26, 2000 at 11:35:22PM -0400, Peter Cordes wrote:
> While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
> that open(1) doesn't work when / is mounted read only.
Already long ago open(1) was renamed to openvt(1), so it may be that
have a very old version. See
On Sun, Nov 26, 2000 at 11:35:22PM -0400, Peter Cordes wrote:
While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
that open(1) doesn't work when / is mounted read only.
Already long ago open(1) was renamed to openvt(1), so it may be that
have a very old version. See a
Andries Brouwer wrote:
access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
You misunderstand the function of access(). The standard says
[EROFS] write access shall fail if write access is requested
for a file on a read-only file system
The intent of the
On Mon, Nov 27, 2000 at 10:47:06PM +0100, Rogier Wolff wrote:
Andries Brouwer wrote:
access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
You misunderstand the function of access(). The standard says
[EROFS] write access shall fail if write access is requested
While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
that open(1) doesn't work when / is mounted read only. It complains that it
"Cannot open /dev/tty2 read/write"...
I straced it:
execve("/usr/bin/open", ["open"], [/* 13 vars */]) = 0
...
brk(0x804c000)
While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
that open(1) doesn't work when / is mounted read only. It complains that it
"Cannot open /dev/tty2 read/write"...
I straced it:
execve("/usr/bin/open", ["open"], [/* 13 vars */]) = 0
...
brk(0x804c000)
48 matches
Mail list logo
