I'm trying to compile version 0.35.12 and 0.36pre30 and I get the same configuration error when running ./configure checking if vnode_if.h needs to be built... configure: error: unable to find any vnode_if script I don't know if this file is supposed to be included in the source, or if it's missing on my system (Mac OSX 10.3, Panther Beta). ~~~Paul Nepywoda
Earlier I posted to the list about changing the local UID to match the AFS UID in Mac OSX. Some people suggest doing this, but I've never come across the true reason behind it. What I'm wondering is, if 2 people have the same local UID, say 501, different AFS UIDs, and login at the same time...can person 1 fool AFS into thinking it owns person 2's files? This seems like a huge security issue to me, so I doubt that would be the case. Does anyone have any definite info about why we should change the local uid and the local file uids to match the AFS uid? thanks, ~~~Paul Nepywoda
On Mon, Aug 18, 2003 at 09:34:19AM -0600, nepywoda <at> fnal.gov wrote: > Earlier I posted to the list about changing the local UID to match the > AFS UID in Mac OSX. Some people suggest doing this, but I've never > come across the true reason behind it. What I'm wondering is, if 2 > people have the same local UID, say 501, different AFS UIDs, and login > at the same time...can person 1 fool AFS into thinking it owns person > 2's files? This seems like a huge security issue to me, so I doubt > that would be the case. AFS always looks at the AFS UID, never at the local UID. At least, it should not. *g* > Does anyone have any definite info about why we should change the > local uid and the local file uids to match the AFS uid? It's primarily of cosmetic nature - you get real user names with "ls -l" (and probably in Finder too). So you actually know who created the file and don't have to guess who is user "1377". Bye, Tino. -- -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/
Right. It's because of a bug in the finder that always looks at UNIX uids and access perms to predetermien if you can access files and folders. OpenAFS 1.2.10 incorporates a patch which works around this problem (and a version of 1.2.9 was released with the patches compiled in). Essentially, the patch sets the file perms so that the finder thinks you have access thus allowing the Finder to actually try and access the file/dir and let AFS allow or deny access based on its perms and your tokens. On 2003.08.18 12:06 Tino Schwarze wrote: > On Mon, Aug 18, 2003 at 09:34:19AM -0600, nepywoda <at> fnal.gov wrote: > > Earlier I posted to the list about changing the local UID to match > the > > AFS UID in Mac OSX. Some people suggest doing this, but I've never > > come across the true reason behind it. What I'm wondering is, if 2 > > people have the same local UID, say 501, different AFS UIDs, and > login > > at the same time...can person 1 fool AFS into thinking it owns > person > > 2's files? This seems like a huge security issue to me, so I doubt > > that would be the case. > > AFS always looks at the AFS UID, never at the local UID. At least, it > should not. *g* > > > Does anyone have any definite info about why we should change the > > local uid and the local file uids to match the AFS uid?(Continue reading)
At 6:06 PM +0200 8/18/03, Tino Schwarze wrote: >On Mon, Aug 18, 2003 at 09:34:19AM -0600, nepywoda <at> fnal.gov wrote: >> Earlier I posted to the list about changing the local UID to match the >> AFS UID in Mac OSX. Some people suggest doing this, but I've never >> come across the true reason behind it. What I'm wondering is, if 2 >> people have the same local UID, say 501, different AFS UIDs, and login >> at the same time...can person 1 fool AFS into thinking it owns person >> 2's files? This seems like a huge security issue to me, so I doubt >> that would be the case. > >AFS always looks at the AFS UID, never at the local UID. At least, it >should not. *g* You know I'm not so sure it's that simple. How are the AFS tokens stored? On OpenAFS I'm pretty sure they're still stored by Unix UID. The standard Unix PAG mechanism isn't implemented because it conflicts with the Security Context done underneath Unix in Mach. Therefore if two different users have the same UID then they share the same AFS token. Does Arla integrate with the Mach Security Context? I know the built-in MIT Kerberos does. -- -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu
----- Original Message ----- From: "Henry B. Hotz" <hotz <at> jpl.nasa.gov> Date: Tuesday, August 19, 2003 2:12 pm Subject: Re: AFS access permissions and OSX interaction > At 6:06 PM +0200 8/18/03, Tino Schwarze wrote: > You know I'm not so sure it's that simple. How are the AFS tokens > stored? > On OpenAFS I'm pretty sure they're still stored by Unix UID. The > standard Unix PAG mechanism isn't implemented because it conflicts > with the Security Context done underneath Unix in Mach. Therefore > if > two different users have the same UID then they share the same AFS > token. > > Does Arla integrate with the Mach Security Context? I know the > built-in MIT Kerberos does. > -- > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu > If 2 users with different usernames authenticate themselves with Kerberos but have the same LOCAL UID...then any Joe can come along with a Kerberos ticket and hack into anyone's files. I'm not very informed on the technical aspects of this authentication, but it seems that logically this wouldn't happen because security itself would break down within AFS. ~~~Paul Nepywoda(Continue reading)
At 7:04 AM -0600 8/20/03, nepywoda <at> fnal.gov wrote: >----- Original Message ----- >From: "Henry B. Hotz" <hotz <at> jpl.nasa.gov> >Date: Tuesday, August 19, 2003 2:12 pm >Subject: Re: AFS access permissions and OSX interaction > > > You know I'm not so sure it's that simple. How are the AFS tokens >> stored? >> On OpenAFS I'm pretty sure they're still stored by Unix UID. The >> standard Unix PAG mechanism isn't implemented because it conflicts >> with the Security Context done underneath Unix in Mach. Therefore > > if two different users have the same UID then they share the same AFS > > token. >> >> Does Arla integrate with the Mach Security Context? I know the > > built-in MIT Kerberos does. > >If 2 users with different usernames authenticate themselves with >Kerberos but have the same LOCAL UID...then any Joe can come along >with a Kerberos ticket and hack into anyone's files. I'm not very >informed on the technical aspects of this authentication, but it >seems that logically this wouldn't happen because security itself >would break down within AFS. If two (different?) users have the same UID then the OS thinks they are the same user and they can hack each other to bits. They still can't touch anyone else with different UIDs. This is just Unix, it's got nothing to do with AFS. In fact I generally have a toor account defined on my machines with UID 0 so I can get root access with the shell I want.(Continue reading)
----- Original Message ----- From: "Henry B. Hotz" <hotz <at> jpl.nasa.gov> Date: Wednesday, August 20, 2003 1:48 pm Subject: Re: AFS access permissions and OSX interaction > If two (different?) users have the same UID then the OS thinks they > are the same user and they can hack each other to bits. They still > can't touch anyone else with different UIDs. This is just Unix, > it's > got nothing to do with AFS. In fact I generally have a toor > account > defined on my machines with UID 0 so I can get root access with the > shell I want. > > My point is that if you have two different users with the same UID > then they share the same AFS tokens (in addition to all other > permissions) unless they are in different PAGs. Kerberos 5 will > try > to associate tickets with login sessions, but the user can still go > get the other session's ticket if he wants (except on MacOS X). > > I'm guessing, but I think the intent of the original question was > could you just create a local group account and hand it out? Each > actual user would then klog to his actual AFS account and go from > there. The answer is that this is a "bad idea" (TM). > > If, on the other hand, each user has a different UID which has no > relation to the AFS UID then you're fine. The only problem is > confusion. You don't even have a problem if a local UID happens to > match up with an AFS UID.(Continue reading)
At 2:14 PM -0500 8/20/03, nepywoda <at> fnal.gov wrote: >----- Original Message ----- >From: "Henry B. Hotz" <hotz <at> jpl.nasa.gov> >Date: Wednesday, August 20, 2003 1:48 pm >Subject: Re: AFS access permissions and OSX interaction >> If two (different?) users have the same UID then the OS thinks they >> are the same user and they can hack each other to bits. They still >> can't touch anyone else with different UIDs. This is just Unix, >> it's >> got nothing to do with AFS. In fact I generally have a toor >> account >> defined on my machines with UID 0 so I can get root access with the >> shell I want. >> >> My point is that if you have two different users with the same UID >> then they share the same AFS tokens (in addition to all other >> permissions) unless they are in different PAGs. Kerberos 5 will >> try >> to associate tickets with login sessions, but the user can still go >> get the other session's ticket if he wants (except on MacOS X). >> >> I'm guessing, but I think the intent of the original question was >> could you just create a local group account and hand it out? Each >> actual user would then klog to his actual AFS account and go from >> there. The answer is that this is a "bad idea" (TM). >> >> If, on the other hand, each user has a different UID which has no >> relation to the AFS UID then you're fine. The only problem is >> confusion. You don't even have a problem if a local UID happens to > > match up with an AFS UID.(Continue reading)
RSS Feed5 | |
|---|---|
4 | |
1 | |
1 | |
12 | |
10 | |
2 | |
15 | |
2 | |
2 | |
3 | |
1 | |
4 | |
1 | |
1 | |
6 | |
7 | |
4 | |
5 | |
13 | |
8 | |
13 | |
9 | |
5 | |
7 | |
1 | |
2 | |
15 | |
33 | |
24 | |
1 | |
11 | |
2 | |
7 | |
7 | |
3 | |
8 | |
1 | |
28 | |
28 | |
1 | |
30 | |
9 | |
30 | |
11 | |
6 | |
43 | |
35 | |
51 | |
26 | |
26 | |
68 | |
23 | |
36 | |
15 | |
16 | |
17 | |
10 | |
5 | |
11 | |
22 | |
27 | |
18 | |
19 | |
28 | |
14 | |
12 | |
41 | |
12 | |
47 | |
47 | |
25 | |
1 | |
37 | |
4 | |
20 | |
8 | |
9 | |
7 | |
9 | |
6 | |
7 | |
16 | |
20 | |
19 | |
30 | |
23 | |
10 | |
39 | |
54 |
