[ tech-userle...@netbsd.org removed from cc:, it's not a userlevel issue
any more ]
On Tue, Aug 24, 1999 at 07:49:02PM +0100, Neil A. Carson wrote:
> ext2fs in Linux already has some support for mount downgrading or forcable
> unomunting (maybe) in the case of an FS error. For something like a
>
[ [EMAIL PROTECTED] removed from cc:, it's not a userlevel issue
any more ]
On Tue, Aug 24, 1999 at 07:49:02PM +0100, Neil A. Carson wrote:
> ext2fs in Linux already has some support for mount downgrading or forcable
> unomunting (maybe) in the case of an FS error. For something like a
> floppy,
ext2fs in Linux already has some support for mount downgrading or forcable
unomunting (maybe) in the case of an FS error. For something like a
floppy, it ought to be possible to force-unmount the disc in the event of
a metadata error.
Neil
To Unsubscribe: send mail to majord...@freebsd
ext2fs in Linux already has some support for mount downgrading or forcable
unomunting (maybe) in the case of an FS error. For something like a
floppy, it ought to be possible to force-unmount the disc in the event of
a metadata error.
Neil
To Unsubscribe: send mail to [EMAIL PROTECTED
>> Solving this is not trivial, I don't think changing the panic() to
>> return(appropriate_error_code) is the rigth thing to do, in some
>> case you want to panic if a filesystem gets corrupted.
> [...consider / or /usr...]
I think an error return is preferable to a panic, during the mount
opera
> Solving this is not trivial, I don't think changing the panic() to
> return(appropriate_error_code) is the rigth thing to do, in some case
> you want to panic if a filesystem gets corrupted.
Indeed, from an overall system robustness perspective, a panic,
reboot, and salvage is, in general, pref
Just FYI, in NetBSD-current, there are on the order of 60 calls to
panic() in sys/ufs/ufs, and 50 calls to panic() in sys/ufs/ffs. There
appear to be similar numbers in ext2fs and lfs.
No doubt some of them are internal consistancy checks which can't be
triggered by on-disk corruption, but still,
On Tue, Aug 24, 1999 at 03:15:09PM +0200, Wolfgang Solfrank wrote:
> Hmm, I think the appropriate thing to do is some equivalent of "panic"ing,
> but only for the filesystem in question. I.e. something like forcibly
> unmounting that filesystem (but maybe continue to return EIO on access to
> anyt
Hi,
> > What I meant to say was that code of the various filesystems currently
> > assumes that the data on the media is somewhat consistent. Since the
> > intention is that Joe User can mount some arbitrary floppy (or zip disk,
> > or ...), the in kernel filesystem code needs to check any data i
On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote:
> [...]
>
> I think the desired behaviour would be that since this is
> effectively now Joe's zip disk, he should be able to do as he
> pleases. One proposal might be to give the console user the
> equivalent of root's priv
On Tue, Aug 24, 1999 at 02:59:09PM +0200, Wolfgang Solfrank wrote:
> [...]
> What I meant to say was that code of the various filesystems currently
> assumes that the data on the media is somewhat consistent. Since the
> intention is that Joe User can mount some arbitrary floppy (or zip disk,
> or
>> Solving this is not trivial, I don't think changing the panic() to
>> return(appropriate_error_code) is the rigth thing to do, in some
>> case you want to panic if a filesystem gets corrupted.
> [...consider / or /usr...]
I think an error return is preferable to a panic, during the mount
oper
Hi,
> > BTW, since non-root users can mount anything, we should make the
> > filesystems'
> > code more robust, so that one cannot take the machine down by inserting
> > random media and mounting it.
>
> They can't mount anything, they need to have access to the block devices.
Of course there a
> Solving this is not trivial, I don't think changing the panic() to
> return(appropriate_error_code) is the rigth thing to do, in some case
> you want to panic if a filesystem gets corrupted.
Indeed, from an overall system robustness perspective, a panic,
reboot, and salvage is, in general, pre
>> BTW, since non-root users can mount anything, we should make the
>> filesystems' code more robust, so that one cannot take the machine
>> down by inserting random media and mounting it.
> They can't mount anything, they need to have access to the block
> devices.
It is not unreasonable for van
Just FYI, in NetBSD-current, there are on the order of 60 calls to
panic() in sys/ufs/ufs, and 50 calls to panic() in sys/ufs/ffs. There
appear to be similar numbers in ext2fs and lfs.
No doubt some of them are internal consistancy checks which can't be
triggered by on-disk corruption, but still
On Tue, Aug 24, 1999 at 03:15:09PM +0200, Wolfgang Solfrank wrote:
> Hmm, I think the appropriate thing to do is some equivalent of "panic"ing,
> but only for the filesystem in question. I.e. something like forcibly
> unmounting that filesystem (but maybe continue to return EIO on access to
> any
On Thu, Aug 19, 1999 at 02:17:49PM +0200, Wolfgang Solfrank wrote:
> BTW, since non-root users can mount anything, we should make the filesystems'
> code more robust, so that one cannot take the machine down by inserting
> random media and mounting it.
They can't mount anything, they need to have
Hi,
> > What I meant to say was that code of the various filesystems currently
> > assumes that the data on the media is somewhat consistent. Since the
> > intention is that Joe User can mount some arbitrary floppy (or zip disk,
> > or ...), the in kernel filesystem code needs to check any data
On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote:
> [...]
>
> I think the desired behaviour would be that since this is
> effectively now Joe's zip disk, he should be able to do as he
> pleases. One proposal might be to give the console user the
> equivalent of root's pri
On Tue, Aug 24, 1999 at 02:59:09PM +0200, Wolfgang Solfrank wrote:
> [...]
> What I meant to say was that code of the various filesystems currently
> assumes that the data on the media is somewhat consistent. Since the
> intention is that Joe User can mount some arbitrary floppy (or zip disk,
> o
Hi,
> > BTW, since non-root users can mount anything, we should make the filesystems'
> > code more robust, so that one cannot take the machine down by inserting
> > random media and mounting it.
>
> They can't mount anything, they need to have access to the block devices.
Of course there are s
>> BTW, since non-root users can mount anything, we should make the
>> filesystems' code more robust, so that one cannot take the machine
>> down by inserting random media and mounting it.
> They can't mount anything, they need to have access to the block
> devices.
It is not unreasonable for va
On Thu, Aug 19, 1999 at 02:17:49PM +0200, Wolfgang Solfrank wrote:
> BTW, since non-root users can mount anything, we should make the filesystems'
> code more robust, so that one cannot take the machine down by inserting
> random media and mounting it.
They can't mount anything, they need to have
On Tue, 17 Aug 1999, Brian C. Grayson wrote:
> On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote:
> > A group of us at Apple are trying to figure out how to handle
> > situations where a filesystem with "foreign" user ID's are present.
>
> Have you looked at mount_umap(8)?
Wilfredo Sanchez wrote:
>
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some examples would help:
>
>
Wilfredo Sanchez wrote:
>
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some examples would help:
>
>
On Wed, 18 Aug 1999, Marc Ramirez wrote:
> Oh! I was under the impression that it just didn't work, even with
> correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first
> time!
It's controlled by a sysctl in Fre
On Tue, 17 Aug 1999, Brian C. Grayson wrote:
> On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote:
> > A group of us at Apple are trying to figure out how to handle
> > situations where a filesystem with "foreign" user ID's are present.
>
> Have you looked at mount_umap(8)
On Wed, 18 Aug 1999, Marc Ramirez wrote:
> Oh! I was under the impression that it just didn't work, even with
> correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first
> time!
It's controlled by a sysctl in Fr
"Justin C. Walker" wrote:
>
> My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS
> doesn't understand identity, permissions, etc., so it can't "talk"
> about them; and (b) when you share a volume from a remote server, you
> "login" to that volume using a mechanism supported by the s
"Justin C. Walker" wrote:
>
> My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS
> doesn't understand identity, permissions, etc., so it can't "talk"
> about them; and (b) when you share a volume from a remote server, you
> "login" to that volume using a mechanism supported by the
> From: Wilfredo Sanchez
> Date: 1999-08-18 14:28:54 -0700
> To: Bill Studenmund
> Subject: Re: Need some advice regarding portable user IDs
> Cc: "Brian C. Grayson"
> ,freebsd-hackers@FreeBSD.ORG,
> tech-userle...@netbsd.org, p...@apple.com,warne...@apple.com,
&
> From: Wilfredo Sanchez <[EMAIL PROTECTED]>
> Date: 1999-08-18 14:28:54 -0700
> To: Bill Studenmund <[EMAIL PROTECTED]>
> Subject: Re: Need some advice regarding portable user IDs
> Cc: "Brian C. Grayson"
> <[EMAIL PROTECTED]>,[EMAIL PROTECTED],
[clipping CC list to include @freebsd.org, @netbsd.org, and @apple.com]
> "Chris" == Chris Dillon writes:
Chris> An origin filesystem (created by and mounted on the same system)
which
Chris> happens to have stuff owned by several different users (this is all
Chris> pseudo... d
[clipping CC list to include @freebsd.org, @netbsd.org, and @apple.com]
> "Chris" == Chris Dillon <[EMAIL PROTECTED]> writes:
Chris> An origin filesystem (created by and mounted on the same system) which
Chris> happens to have stuff owned by several different users (this is all
Hi,
> huh? NetBSD (at least) allows non-root mounts (forced to
> nodev,nosuid, ..) if the user owns the mount point and has appropriate
> access to the underlying device..
>
> I thought that was a 4.4Lite feature..
BTW, since non-root users can mount anything, we should make the filesystems'
co
Hi,
> huh? NetBSD (at least) allows non-root mounts (forced to
> nodev,nosuid, ..) if the user owns the mount point and has appropriate
> access to the underlying device..
>
> I thought that was a 4.4Lite feature..
BTW, since non-root users can mount anything, we should make the filesystems'
c
"Ronald G. Minnich" wrote:
>
> the only portable user ids are names as strings. you can kludge and kludge
> but at some point the kludges will pile up too high, fall over, and hurt
> somebody. how many new options did we see proposed in the last 12 hours
> for this problem?
Actually, I think that
"Ronald G. Minnich" wrote:
>
> the only portable user ids are names as strings. you can kludge and kludge
> but at some point the kludges will pile up too high, fall over, and hurt
> somebody. how many new options did we see proposed in the last 12 hours
> for this problem?
Actually, I think tha
On Wed, 18 Aug 1999, Chris Dillon wrote:
> I'm probably being extremely naive myself, but I just envisioned a
> scenario like this (pardon me if someone else has already suggested
> this):
>
> When a filesystem is mounted as foreign (HOW that is determined I
> won't talk about), every file in the
On Wed, 18 Aug 1999, Bill Studenmund wrote:
> On Tue, 17 Aug 1999, Brian C. Grayson wrote:
>
> > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote:
> > > A group of us at Apple are trying to figure out how to handle
> > > situations where a filesystem with "foreign" user ID's a
On Wed, 18 Aug 1999, Chris Dillon wrote:
> I'm probably being extremely naive myself, but I just envisioned a
> scenario like this (pardon me if someone else has already suggested
> this):
>
> When a filesystem is mounted as foreign (HOW that is determined I
> won't talk about), every file in th
On Wed, 18 Aug 1999, Wilfredo Sanchez wrote:
> I think Mac OS 8 will forget about the credentials. I don't
> actually know much about how sharing works.
>
> But the current file sharing behaviour is not entirely useful to
> think about, because it doesn't effect the local permissions (mu
Wilfredo Sanchez wrote:
>
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some examples would help:
>
>
| Fred, right now what happens in MacOS when I take a disk which has
sharing
| credentials set up, and hook it into another machine? How are the
| credentials handled there?
I think Mac OS 8 will forget about the credentials. I don't
actually know much about how sharing works.
But the cu
On Wed, 18 Aug 1999, Bill Studenmund wrote:
> On Tue, 17 Aug 1999, Brian C. Grayson wrote:
>
> > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote:
> > > A group of us at Apple are trying to figure out how to handle
> > > situations where a filesystem with "foreign" user ID's
On Wed, 18 Aug 1999, Anthony Kimball wrote:
>
> : And what happens accross NIS domains?
>
> UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not
> Steve.
>
ROTFLMFAO (rolling on the floor laughing my f***ing a** off) ;^)
Thanks for brightening my day with this grin
: And what happens accross NIS domains?
UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not Steve.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
On Wed, 18 Aug 1999, Wilfredo Sanchez wrote:
> I think Mac OS 8 will forget about the credentials. I don't
> actually know much about how sharing works.
>
> But the current file sharing behaviour is not entirely useful to
> think about, because it doesn't effect the local permissions (m
Wilfredo Sanchez wrote:
>
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some examples would help:
>
>
| Fred, right now what happens in MacOS when I take a disk which has
sharing
| credentials set up, and hook it into another machine? How are the
| credentials handled there?
I think Mac OS 8 will forget about the credentials. I don't
actually know much about how sharing works.
But the c
On Wed, 18 Aug 1999, Anthony Kimball wrote:
>
> : And what happens accross NIS domains?
>
> UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not
> Steve.
>
ROTFLMFAO (rolling on the floor laughing my f***ing a** off) ;^)
Thanks for brightening my day with this grin
On Tue, 17 Aug 1999, Brian C. Grayson wrote:
> On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote:
> > A group of us at Apple are trying to figure out how to handle
> > situations where a filesystem with "foreign" user ID's are present.
>
> Have you looked at mount_umap(8)?
: And what happens accross NIS domains?
UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not Steve.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Wed, 18 Aug 1999, Marc Ramirez wrote:
> Oh! I was under the impression that it just didn't work, even with
> correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first
> time!
It's controlled by a sysctl in Fre
On Tue, 17 Aug 1999, Brian C. Grayson wrote:
> On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote:
> > A group of us at Apple are trying to figure out how to handle
> > situations where a filesystem with "foreign" user ID's are present.
>
> Have you looked at mount_umap(8)
On Wed, 18 Aug 1999, Marc Ramirez wrote:
> Oh! I was under the impression that it just didn't work, even with
> correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first
> time!
It's controlled by a sysctl in Fr
| > when new media is available and it will try to mount it. The
present
| > behaviour in Mac OS X Server is that everything mounted this
way is
| > trusted, though the Finder should be requesting nosetuid; I should
| > check that. It's also possible that the kernel will number
drive
| > when new media is available and it will try to mount it. The
present
| > behaviour in Mac OS X Server is that everything mounted this
way is
| > trusted, though the Finder should be requesting nosetuid; I should
| > check that. It's also possible that the kernel will number
driv
On Wed, 18 Aug 1999, David Malone wrote:
> On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote:
> > Oh! I was under the impression that it just didn't work, even with
> > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> > with 0666 on /dev/fd0. Maybe I'm being stup
the only portable user ids are names as strings. you can kludge and kludge
but at some point the kludges will pile up too high, fall over, and hurt
somebody. how many new options did we see proposed in the last 12 hours
for this problem?
ron
To Unsubscribe: send mail to majord...@freebsd.org
On Wed, 18 Aug 1999, David Malone wrote:
> On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote:
> > Oh! I was under the impression that it just didn't work, even with
> > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> > with 0666 on /dev/fd0. Maybe I'm being stu
the only portable user ids are names as strings. you can kludge and kludge
but at some point the kludges will pile up too high, fall over, and hurt
somebody. how many new options did we see proposed in the last 12 hours
for this problem?
ron
To Unsubscribe: send mail to [EMAIL PROTECTED]
wit
> "Wilfredo" == Wilfredo Sanchez writes:
Wilfredo> I think the desired behaviour would be that since this is
Wilfredo> effectively now Joe's zip disk, he should be able to do as he
Wilfredo> pleases. One proposal might be to give the console user the
Wilfredo> equival
> "Wilfredo" == Wilfredo Sanchez <[EMAIL PROTECTED]> writes:
Wilfredo> I think the desired behaviour would be that since this is
Wilfredo> effectively now Joe's zip disk, he should be able to do as he
Wilfredo> pleases. One proposal might be to give the console user the
Hi,
> huh? NetBSD (at least) allows non-root mounts (forced to
> nodev,nosuid, ..) if the user owns the mount point and has appropriate
> access to the underlying device..
>
> I thought that was a 4.4Lite feature..
Yes, it was part of 4.4Lite2.
And I still have the discussion from 1994 between
On 18 Aug, Marc Ramirez wrote:
> Oh! I was under the impression that it just didn't work, even with
> correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first
> time!
>
> Marc.
No miracle, the mount command has
On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote:
> Oh! I was under the impression that it just didn't work, even with
> correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first
> time!
You have to tu
[ CC's trimmed ]
On Wed, 18 Aug 1999, Bill Sommerfeld wrote:
> > Yeah. That's definitely where I'd start from. I think the main obstacle
> > for any *BSD system in the ease-of-use department will be the
> > must-mount-as-root issue.
>
> huh? NetBSD (at least) allows non-root mounts (forced
I had a thought on this
It seems you are trying to provide the "floppy model" that users
currently have with their PCs.
User A writes the floppy, User B can read it and do whatever he
wants...
(I know this is Apple - but I'll stick to MSDOS for the discussion,
and "floppy" indicates any re
Hi,
> huh? NetBSD (at least) allows non-root mounts (forced to
> nodev,nosuid, ..) if the user owns the mount point and has appropriate
> access to the underlying device..
>
> I thought that was a 4.4Lite feature..
Yes, it was part of 4.4Lite2.
And I still have the discussion from 1994 betwee
> Yeah. That's definitely where I'd start from. I think the main obstacle
> for any *BSD system in the ease-of-use department will be the
> must-mount-as-root issue.
huh? NetBSD (at least) allows non-root mounts (forced to
nodev,nosuid, ..) if the user owns the mount point and has appropriate
On 18 Aug, Marc Ramirez wrote:
> Oh! I was under the impression that it just didn't work, even with
> correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first
> time!
>
> Marc.
No miracle, the mount command ha
On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote:
> Oh! I was under the impression that it just didn't work, even with
> correct perms, but I use FreeBSD. Lemme try it... Can't mount, even
> with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first
> time!
You have to t
[ CC's trimmed ]
On Wed, 18 Aug 1999, Bill Sommerfeld wrote:
> > Yeah. That's definitely where I'd start from. I think the main obstacle
> > for any *BSD system in the ease-of-use department will be the
> > must-mount-as-root issue.
>
> huh? NetBSD (at least) allows non-root mounts (force
I had a thought on this
It seems you are trying to provide the "floppy model" that users
currently have with their PCs.
User A writes the floppy, User B can read it and do whatever he
wants...
(I know this is Apple - but I'll stick to MSDOS for the discussion,
and "floppy" indicates any r
On Wed, 18 Aug 1999, Ignatios Souvatzis wrote:
> On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote:
> >
> > I was thinking about this the other day, while mousting a series of floppy
> > disks, and it seems to me that what you're looking for, at least for
> > removable media, is a sort
> Yeah. That's definitely where I'd start from. I think the main obstacle
> for any *BSD system in the ease-of-use department will be the
> must-mount-as-root issue.
huh? NetBSD (at least) allows non-root mounts (forced to
nodev,nosuid, ..) if the user owns the mount point and has appropriat
On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote:
>
> I was thinking about this the other day, while mousting a series of floppy
> disks, and it seems to me that what you're looking for, at least for
> removable media, is a sort of single-user UFS that says "Joe Schmoe owns
> this file
On Tue, 17 Aug 1999, Wilfredo Sanchez wrote:
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
[...]
> that he can't read the files, because I have a lamer umask, and as a
> bonus, I don't have an account
On Wed, 18 Aug 1999, Ignatios Souvatzis wrote:
> On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote:
> >
> > I was thinking about this the other day, while mousting a series of floppy
> > disks, and it seems to me that what you're looking for, at least for
> > removable media, is a sor
On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote:
>
> I was thinking about this the other day, while mousting a series of floppy
> disks, and it seems to me that what you're looking for, at least for
> removable media, is a sort of single-user UFS that says "Joe Schmoe owns
> this fil
On Tue, 17 Aug 1999, Wilfredo Sanchez wrote:
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some
On Tue, 17 Aug 1999, Wilfredo Sanchez wrote:
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
[...]
> that he can't read the files, because I have a lamer umask, and as a
> bonus, I don't have an account
On Tue, 17 Aug 1999, Wilfredo Sanchez wrote:
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some examples would help:
Basically, you have two
+[ Wilfredo Sanchez ]-
| A group of us at Apple are trying to figure out how to handle
| situations where a filesystem with "foreign" user ID's are present.
| The basic problem is that the user experience using Unix semantics
| are not really
On 18-Aug-99 Wilfredo Sanchez wrote:
> when new media is available and it will try to mount it. The present
> behaviour in Mac OS X Server is that everything mounted this way is
> trusted, though the Finder should be requesting nosetuid; I should
> check that. It's also possible that t
At 7:17 PM -0700 8/17/99, Wilfredo Sanchez wrote:
I think the desired behaviour would be that since this is
effectively now Joe's zip disk, he should be able to do as he
pleases. One proposal might be to give the console user the
equivalent of root's priveledges on any removeable media he inser
| I suppose you could carry a UID, GID mapping on the disks, and
have mount look
| out for it.. If you had a 'removable disk' flag in /etc/fstab,
then have the
| kernel look for those files, and use umapfs with them on the
mounted FS. It
| could be rather dangerous security wise though.. Mayb
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
> The basic problem is that the user experience using Unix semantics
> are not really pleasant. I think some examples would help:
Basically, you have two
+[ Wilfredo Sanchez ]-
| A group of us at Apple are trying to figure out how to handle
| situations where a filesystem with "foreign" user ID's are present.
| The basic problem is that the user experience using Unix semantics
| are not reall
On Tue, Aug 17, 1999 at 07:46:37PM -0700, Wilfredo Sanchez wrote:
> Yes, the fancy command is what the Finder does for him. Options
> are details, and not really interesting. The question is what should
> the behaviour be, and what's happening underneath the covers to
> support that? Are
On 18-Aug-99 Wilfredo Sanchez wrote:
> when new media is available and it will try to mount it. The present
> behaviour in Mac OS X Server is that everything mounted this way is
> trusted, though the Finder should be requesting nosetuid; I should
> check that. It's also possible that
At 7:17 PM -0700 8/17/99, Wilfredo Sanchez wrote:
> I think the desired behaviour would be that since this is
>effectively now Joe's zip disk, he should be able to do as he
>pleases. One proposal might be to give the console user the
>equivalent of root's priveledges on any removeable media he i
| I suppose you could carry a UID, GID mapping on the disks, and
have mount look
| out for it.. If you had a 'removable disk' flag in /etc/fstab,
then have the
| kernel look for those files, and use umapfs with them on the
mounted FS. It
| could be rather dangerous security wise though.. May
At 12:25 PM +0930 8/18/99, Daniel O'Connor wrote:
On 18-Aug-99 Wilfredo Sanchez wrote:
>Joe doesn't use the shell. The Finder will do this for him; when
> you insert a floppy in Mac OS, it gets mounted and shows up on your
> desktop. This is the case with all media.
Yes... Why is this a
On Tue, Aug 17, 1999 at 07:46:37PM -0700, Wilfredo Sanchez wrote:
> Yes, the fancy command is what the Finder does for him. Options
> are details, and not really interesting. The question is what should
> the behaviour be, and what's happening underneath the covers to
> support that? Ar
On 18-Aug-99 Wilfredo Sanchez wrote:
>I'm trying to support a user experience similar to Mac OS using
> BSD underneath (for Mac OS version 10). The goal being simplicity
> for the user, which I think might interest some FreeBSD users as well
> as my customers.
Right.. sorry, I didn'
1 - 100 of 122 matches
Mail list logo
