Exporting UID to userspace?

Exporting UID to userspace?

[Dimitry V. Ketov]

Hi, autofs hackers!

Is it possible with the current autofs protocol to export UID of (mount)
requesting process to the userspace automount daemon? If not, I guess
that it is rather trivial feature enhancement request ;)
The matter of this RFE is need to mount smbfs shares on behalf of
requestng users, with their own passwords...

Thanks in advance,
Dimitry.

Re: Exporting UID to userspace?

[raven]

On Sat, 5 Jun 2004, Dimitry V. Ketov wrote:

> Hi, autofs hackers!
> 
> Is it possible with the current autofs protocol to export UID of (mount)
> requesting process to the userspace automount daemon? If not, I guess
> that it is rather trivial feature enhancement request ;)
> The matter of this RFE is need to mount smbfs shares on behalf of
> requestng users, with their own passwords...

This has been raised before.

I'd like to do it but it isn't trivial so it's in the wait queue.

It's dificult because it requires that the packet which is used to 
communicate with the daemon will need to be changed. This will break 
backward compatibility with other versions.

Ian

Re: Exporting UID to userspace?

[raven]

On Sat, 5 Jun 2004 raven@themaw.net wrote:

> On Sat, 5 Jun 2004, Dimitry V. Ketov wrote:
> 
> > Hi, autofs hackers!
> > 
> > Is it possible with the current autofs protocol to export UID of (mount)
> > requesting process to the userspace automount daemon? If not, I guess
> > that it is rather trivial feature enhancement request ;)
> > The matter of this RFE is need to mount smbfs shares on behalf of
> > requestng users, with their own passwords...
> 
> This has been raised before.
> 
> I'd like to do it but it isn't trivial so it's in the wait queue.
> 
> It's dificult because it requires that the packet which is used to 
> communicate with the daemon will need to be changed. This will break 
> backward compatibility with other versions.
> 

In fact it gets worse.

How will you provide a consistent Unix UID <-> Windows UID mapping?

And on multiple machines for the same user, over OS re-install?

Ian

Re: Exporting UID to userspace?

[Robin Rosenberg]

On Saturday 05 June 2004 17.52, raven@themaw.net wrote:
> > > The matter of this RFE is need to mount smbfs shares on behalf of
> > > requestng users, with their own passwords...
> > This has been raised before.
> > I'd like to do it but it isn't trivial so it's in the wait queue.
> > It's dificult because it requires that the packet which is used to
> > communicate with the daemon will need to be changed. This will break
> > backward compatibility with other versions.
..
> How will you provide a consistent Unix UID <-> Windows UID mapping?
> And on multiple machines for the same user, over OS re-install?
> Ian

Assuming that is a problemm... It's not for me. 

It's not an autofs problem. It's the user space problem to figure that. 
Winbind is one possibility, but other's are possible. In some settings u can
simply use the same name and assume the same name goes for windows. In other 
cases you can use a mapping table in the script that automount calls. Autofs
should just provide the local uid,gid from the calling process.

-- robin

Re: Exporting UID to userspace?

[Ian Kent]

On Sat, 5 Jun 2004, Robin Rosenberg wrote:

> On Saturday 05 June 2004 17.52, raven@themaw.net wrote:
> > > > The matter of this RFE is need to mount smbfs shares on behalf of
> > > > requestng users, with their own passwords...
> > > This has been raised before.
> > > I'd like to do it but it isn't trivial so it's in the wait queue.
> > > It's dificult because it requires that the packet which is used to
> > > communicate with the daemon will need to be changed. This will break
> > > backward compatibility with other versions.
> ..
> > How will you provide a consistent Unix UID <-> Windows UID mapping?
> > And on multiple machines for the same user, over OS re-install?
> > Ian
>
> Assuming that is a problemm... It's not for me.
>
> It's not an autofs problem. It's the user space problem to figure that.
> Winbind is one possibility, but other's are possible. In some settings u can
> simply use the same name and assume the same name goes for windows. In other
> cases you can use a mapping table in the script that automount calls. Autofs
> should just provide the local uid,gid from the calling process.

The main point was that the uid and gid is not available to autofs
without kernel and userspace modification which will break backward
compatibility.

For userspace a new mount module would need to be developed from scratch.
A fair amount of work.

Ian

Re: Exporting UID to userspace?

[Robin Rosenberg]

On Saturday 05 June 2004 19.49, Ian Kent wrote:
> For userspace a new mount module would need to be developed from scratch.
> A fair amount of work.

I'm not disputing that.  

-- robin

RE: Exporting UID to userspace?

[Dimitry V. Ketov]

> -----Original Message-----
> From: raven@themaw.net [mailto:raven@themaw.net] 
> Sent: Saturday, June 05, 2004 7:47 PM

> I'd like to do it but it isn't trivial so it's in the wait queue.
> 
> It's dificult because it requires that the packet which is used to 
> communicate with the daemon will need to be changed. This will break 
> backward compatibility with other versions.

Ok. Is it mean that it will be included only in the next version of
autofs protocol?

Dimitry.

RE: Exporting UID to userspace?

[Dimitry V. Ketov]

> -----Original Message-----
> From: Robin Rosenberg [mailto:robin.rosenberg.lists@dewire.com] 
> 
> On Saturday 05 June 2004 17.52, raven@themaw.net wrote:
> ..
> > How will you provide a consistent Unix UID <-> Windows UID mapping? 
> > And on multiple machines for the same user, over OS re-install? Ian
> 
> cases you can use a mapping table in the script that 
> automount calls. Autofs should just provide the local uid,gid 
> from the calling process.

Yes, you're definitely right. In fact I want this finctionality just for
'program' maps, lets say UID, GID and supplementary GIDs like a second,
third, so on ... parameters to the map script.

Dimitry.

Re: Exporting UID to userspace?

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dimitry V. Ketov wrote:
>
>>-----Original Message-----
>>From: Robin Rosenberg [mailto:robin.rosenberg.lists@dewire.com]
>>
>>On Saturday 05 June 2004 17.52, raven@themaw.net wrote:
>>..
>>
>>>How will you provide a consistent Unix UID <-> Windows UID mapping?
>>>And on multiple machines for the same user, over OS re-install? Ian
>>
>>cases you can use a mapping table in the script that
>>automount calls. Autofs should just provide the local uid,gid
>>from the calling process.
>
>
> Yes, you're definitely right. In fact I want this finctionality just for
> 'program' maps, lets say UID, GID and supplementary GIDs like a second,
> third, so on ... parameters to the map script.
>

My real problem with this RFE is that there is no indication on how you
are planning to acquire the user credentials.

For instance:
- - how are you going to acquire terminal information with just a uid/gid
pair?
- - how are you going to handle the case where there was no terminal?
- - what about when there was no terminal, but there were X resources
available? (kernelspace wouldn't know anything about this at all..)


Shouldn't this RFE also include some proposal for how you are going to
ensure that only a single uid ever attempts access to the automounted
directory as well? (if needed?)


The current work-around is to have the credentials supplied by the map
itself.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAxJKPdQs4kOxk3/MRAuX9AJ9FVcGKhOMzPLFkHspT02CiattpMQCdH56m
/AkQpZ1/5XmoGL+9cJ8poE0=
=9W5D
-----END PGP SIGNATURE-----

Re: Exporting UID to userspace?

[Robin Rosenberg]

On Monday 07 June 2004 18.06, Mike Waychison wrote:
> My real problem with this RFE is that there is no indication on how you
> are planning to acquire the user credentials.
Does it matter if you know it  *is* possible. My idea is to do as I do today,
but with an extra lookup based on uid. That is the script executed by
automount would 

> For instance:
> - how are you going to acquire terminal information with just a uid/gid
> pair?
Simple case: don't need it. Assume the user has entered all info in a file
named ~uid/.autofs/credentials
host, share, remoteuid,remotepass

I'm a samba user so I could think of using Smb4K or similar to set up 

Or like the gpg agent that can bring up a window. 
~uid/.autofspipe

But I'd simply use the first version to start with.

> - how are you going to handle the case where there was no terminal?
> - what about when there was no terminal, but there were X resources
> available? (kernelspace wouldn't know anything about this at all..)

> Shouldn't this RFE also include some proposal for how you are going to
> ensure that only a single uid ever attempts access to the automounted
> directory as well? (if needed?)
Well, uh.. 
..good point. 

The directory can be shared if the permissions allow it so there is no 
absolute requirement for always separating users (but probably that is
the common need). But that's more of an extra feature for those file systems 
that support this.

I was thinking of ~uid/Network\ Neighborhood, but then autofs cannot do
/home/*/Network\ Neighborhood, I think.

Come to think of it.. There's a product called Sharity that does this. 
Actually it seem to do exactly what I want for CIFS without automount. 
Everything gets listed under /CIFS. The mount deamon talks to an agent 
running on the user's terminal, X or wherever the user decides and prompts 
for credentials if necessary. If no agent is running its can read info from a
pre-setup file or access will fail.

-- robin

RE: Exporting UID to userspace?

[Ian Kent]

On Mon, 7 Jun 2004, Dimitry V. Ketov wrote:

> > -----Original Message-----
> > From: raven@themaw.net [mailto:raven@themaw.net] 
> > Sent: Saturday, June 05, 2004 7:47 PM
> 
> > I'd like to do it but it isn't trivial so it's in the wait queue.
> > 
> > It's dificult because it requires that the packet which is used to 
> > communicate with the daemon will need to be changed. This will break 
> > backward compatibility with other versions.
> 
> Ok. Is it mean that it will be included only in the next version of
> autofs protocol?

Perhaps but probably not. It means that, if the kernel module changes are 
accepted and the changes are made to the autofs daemon, then from that 
time on the kernel module will only work with the corresponding later 
versions of the autofs daemon and the daemon will require that version or 
later of the kernel module. This is not something that can be taken 
lightly. I will think about this for a while and see if I can come up with 
some way to do it.

Fact is I'm still struggling to get bugs fixed. When that has settled down 
there are a couple of quite serious limitations with autofs that need to 
be addressed. They've been outstanding for many months.

Ian

RE: Exporting UID to userspace?

[Brian Long]

> Fact is I'm still struggling to get bugs fixed. When that has settled down 
> there are a couple of quite serious limitations with autofs that need to 
> be addressed. They've been outstanding for many months.

Ian,

Could you remind us what "serious limitations" still exist in autofs? 
Is this in comparison to Sun's implementation on Solaris or something
else?

/Brian/

-- 
       Brian Long                      |         |           |
       Americas IT Hosting Sys Admin   |       .|||.       .|||.
       Cisco Linux Developer           |   ..:|||||||:...:|||||||:..
       Phone: (919) 392-7363           |   C i s c o   S y s t e m s

RE: Exporting UID to userspace?

[raven]

On Tue, 8 Jun 2004, Brian Long wrote:

> 
> > Fact is I'm still struggling to get bugs fixed. When that has settled down 
> > there are a couple of quite serious limitations with autofs that need to 
> > be addressed. They've been outstanding for many months.
> 
> Ian,
> 
> Could you remind us what "serious limitations" still exist in autofs? 
> Is this in comparison to Sun's implementation on Solaris or something
> else?

Lazy mounting of multi-mount map entries.
Direct mounts obscure underlying file system high up in the tree.

Yes this is what people expect from an automounter as Suns implementation 
provides it. In any case I've needed it for ages and I have some fairly 
clear ideas on how to implement it, after having given it much thought.

Don't get me wrong here, the big issue with this request is working out a 
way to get hold of the UID and GID or perhaps GIDs without having to 
compromise the existing system.

Do you guys have any ideas on how we might do this?

Ian

RE: Exporting UID to userspace?

[Dimitry V. Ketov]

> -----Original Message-----
> From: Robin Rosenberg [mailto:robin.rosenberg.lists@dewire.com]
> 
> On Monday 07 June 2004 18.06, Mike Waychison wrote:
> > - how are you going to acquire terminal information with just a
> > uid/gid pair?
> Simple case: don't need it. Assume the user has entered all
> info in a file named ~uid/.autofs/credentials
> host, share, remoteuid,remotepass
Yes, I supposed the same trivial way to deal with that.

> > Shouldn't this RFE also include some proposal for how you 
> are going to 
> > ensure that only a single uid ever attempts access to the 
> automounted 
> > directory as well? (if needed?)
> Well, uh.. 
> ..good point. 
> I was thinking of ~uid/Network\ Neighborhood, but then autofs 
> cannot do /home/*/Network\ Neighborhood, I think.
I think it is possible to spawn a new automount process (with the
~uid/Network\ Neighborhood automount-point and the special executable
map) for every logged user, with the help of the special pam module.

Dimitry.

Re: Exporting UID to userspace?

[Robin Rosenberg]

On Tuesday 08 June 2004 19.47, Dimitry V. Ketov wrote:
> I think it is possible to spawn a new automount process (with the
> ~uid/Network\ Neighborhood automount-point and the special executable
> map) for every logged user, with the help of the special pam module.

Ah. Ofcourse!  Thanks.

-- robin

Re: Exporting UID to userspace?

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

raven@themaw.net wrote:
> On Tue, 8 Jun 2004, Brian Long wrote:
>
>
>>>Fact is I'm still struggling to get bugs fixed. When that has settled
down
>>>there are a couple of quite serious limitations with autofs that need to
>>>be addressed. They've been outstanding for many months.
>>
>>Ian,
>>
>>Could you remind us what "serious limitations" still exist in autofs?
>>Is this in comparison to Sun's implementation on Solaris or something
>>else?
>
>
> Lazy mounting of multi-mount map entries.
> Direct mounts obscure underlying file system high up in the tree.
>
> Yes this is what people expect from an automounter as Suns implementation
> provides it. In any case I've needed it for ages and I have some fairly
> clear ideas on how to implement it, after having given it much thought.
>
> Don't get me wrong here, the big issue with this request is working out a
> way to get hold of the UID and GID or perhaps GIDs without having to
> compromise the existing system.
>
> Do you guys have any ideas on how we might do this?
>
> Ian

If the idea is to have a 'Network Neighborhood' inside each user's
homedir, you could write an executable map for /home (not tested..):

key = shift
entry = `ypcat $KEY -k`
if [ $? == 0 ] ; then
   echo $entry " /NetworkNeighborhood -Duser=$key /etc/auto_nn"
   exit 0
fi;
exit 1

And then use a auto_nn executable map for generating the Neighborhood
contents.

To handle mounting with credentials, you'll have to

a) adapt the existing modules to handle grabbing credentials

or

b) write a generic 'execmount' module that will execute a given script
with all the required information (all the environment variables, mount
options, real filesystem type, yadda yadda).   This is my preferred
approach to handling this as it can be re-used for other strange
automount uses..

This method also means that you don't have to touch the kernel module at
all..

What think?

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAxglEdQs4kOxk3/MRAl0jAJ9NzCQq0c4AZ8r2DupTP2hilZ6CXQCeIWKu
hEQ6VbhSVaURsqIPW9tRboM=
=CzDF
-----END PGP SIGNATURE-----

RE: Exporting UID to userspace?

[Dimitry V. Ketov]

> -----Original Message-----
> From: autofs-bounces@linux.kernel.org 
> 
> If the idea is to have a 'Network Neighborhood' inside each 
> user's homedir, you could write an executable map for /home 

It will hide /home directory content.

> (not tested..):

> key = shift
Did you mean key=$1 ?

> entry = `ypcat $KEY -k`
What did you mean for $KEY? What is supposed to assign to the 'entry'
variable?

> if [ $? == 0 ] ; then
>    echo $entry " /NetworkNeighborhood -Duser=$key /etc/auto_nn"
>    exit 0
> fi;
> exit 1
> 
> And then use a auto_nn executable map for generating the 
> Neighborhood contents.

Re: Exporting UID to userspace?

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dimitry V. Ketov wrote:
>>-----Original Message-----
>>From: autofs-bounces@linux.kernel.org
>>
>>If the idea is to have a 'Network Neighborhood' inside each
>>user's homedir, you could write an executable map for /home
>
>
> It will hide /home directory content.

No. It wouldn't presuming that your /home subdirs are automounted.  The
script would basically transform map entries like:

mikew	-wsize=32768,rsize=32768  homedirserver:/export/home/mikew

Into:
mikew	-wsize=32768,rsize=32768  homedirserver:/export/home/mikew \
  /NetworkNeighborhood	-fstype=autofs,Duser=mikew /etc/auto_nn

which is a valid multimount and should be handled correctly by automount 4.

>
>
>>(not tested..):
>
>
>>key = shift
>
> Did you mean key=$1 ?
>

Sure.


>
>>entry = `ypcat $KEY -k`
>
> What did you mean for $KEY? What is supposed to assign to the 'entry'
> variable?
>

I meant $key.

>
>>if [ $? == 0 ] ; then
>>   echo $entry " /NetworkNeighborhood -Duser=$key /etc/auto_nn"
>>   exit 0
>>fi;
>>exit 1
>>
>>And then use a auto_nn executable map for generating the
>>Neighborhood contents.
>
>
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs


- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAx1qIdQs4kOxk3/MRAk0/AJ0bw0kqFk4qX72h6q+TULhM7qxWYACdENrq
N9IAdc+f5D9aeu2VG3g4DQ8=
=Rp37
-----END PGP SIGNATURE-----

Re: Exporting UID to userspace?

[Ian Kent]

On Wed, 9 Jun 2004, Mike Waychison wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dimitry V. Ketov wrote:
> >>-----Original Message-----
> >>From: autofs-bounces@linux.kernel.org
> >>
> >>If the idea is to have a 'Network Neighborhood' inside each
> >>user's homedir, you could write an executable map for /home
> >
> >
> > It will hide /home directory content.
> 
> No. It wouldn't presuming that your /home subdirs are automounted.  The
> script would basically transform map entries like:
> 
> mikew	-wsize=32768,rsize=32768  homedirserver:/export/home/mikew
> 
> Into:
> mikew	-wsize=32768,rsize=32768  homedirserver:/export/home/mikew \
>   /NetworkNeighborhood	-fstype=autofs,Duser=mikew /etc/auto_nn
> 
> which is a valid multimount and should be handled correctly by automount 4.

And this brings us to the lazy mounting issue for multi-mounts.

Got to get some more time on that.

Ian

RE: Exporting UID to userspace?

[Dimitry V. Ketov]

> -----Original Message-----
> From: Ian Kent [mailto:raven@themaw.net] 

> > >>If the idea is to have a 'Network Neighborhood' inside 
> each user's 
> > >>homedir, you could write an executable map for /home
> > >
> > > It will hide /home directory content.
> > 
> > No. It wouldn't presuming that your /home subdirs are automounted.  

What if my home dirs is not automounted from network server?
I just simply want it for local users.

Dimitry.

Re: Exporting UID to userspace?

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dimitry V. Ketov wrote:
>>-----Original Message-----
>>From: Ian Kent [mailto:raven@themaw.net]
>
>
>>>>>If the idea is to have a 'Network Neighborhood' inside
>>
>>each user's
>>
>>>>>homedir, you could write an executable map for /home
>>>>
>>>>It will hide /home directory content.
>>>
>>>No. It wouldn't presuming that your /home subdirs are automounted.
>
>
> What if my home dirs is not automounted from network server?
> I just simply want it for local users.
>

Well, in that case you'd have to use direct mounts (which don't work as
expected in automount4).  Alternatively, you can always

mkdir /export
mv /home /export

And start automounting your home directories from localhost.   Don't
worry, automount will detect it being local and will not use NFS, rather
it will --bind mount the filesystems, so there is no performance hit.

HTH,


- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAyIQedQs4kOxk3/MRAot8AJ9bon1pulFLyND8Q3mn77EmqO2QWgCghPEu
nhSCC2WXE+JmPfqb+bqhM24=
=0h86
-----END PGP SIGNATURE-----

RE: Exporting UID to userspace?

[Dimitry V. Ketov]

> -----Original Message-----
> From: Mike Waychison [mailto:Michael.Waychison@Sun.COM] 

>>>>>If the idea is to have a 'Network Neighborhood' inside
> >>each user's
> >>>>>homedir, you could write an executable map for /home
> >>>>
> >>>>It will hide /home directory content.
> >>>
> >>>No. It wouldn't presuming that your /home subdirs are automounted.
> >
> >
> > What if my home dirs is not automounted from network server? I just 
> > simply want it for local users.
> >
> 
> Well, in that case you'd have to use direct mounts (which 
> don't work as expected in automount4).  Alternatively, you can always
> 
> mkdir /export
> mv /home /export
> 
> And start automounting your home directories from localhost.   Don't
> worry, automount will detect it being local and will not use 
> NFS, rather it will --bind mount the filesystems, so there is 
> no performance hit.
;) Yes, I thought about it, but it's rather ugly solution (as for me),
then it's seems better to spawn new automount process for
~user/NetworkNeigboorhood at logon time and terminate it at logoff.
This allows us to avoid UID/GID exporting problem at all, since it will
be obvious which user's credetials to use for mount.

Any objections?

Dimitry.

Re: Exporting UID to userspace?

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dimitry V. Ketov wrote:
>>-----Original Message-----
>>From: Mike Waychison [mailto:Michael.Waychison@Sun.COM]
>
>
>>>>>>If the idea is to have a 'Network Neighborhood' inside
>>>>
>>>>each user's
>>>>
>>>>>>>homedir, you could write an executable map for /home
>>>>>>
>>>>>>It will hide /home directory content.
>>>>>
>>>>>No. It wouldn't presuming that your /home subdirs are automounted.
>>>
>>>
>>>What if my home dirs is not automounted from network server? I just
>>>simply want it for local users.
>>>
>>
>>Well, in that case you'd have to use direct mounts (which
>>don't work as expected in automount4).  Alternatively, you can always
>>
>>mkdir /export
>>mv /home /export
>>
>>And start automounting your home directories from localhost.   Don't
>>worry, automount will detect it being local and will not use
>>NFS, rather it will --bind mount the filesystems, so there is
>>no performance hit.
>
> ;) Yes, I thought about it, but it's rather ugly solution (as for me),
> then it's seems better to spawn new automount process for
> ~user/NetworkNeigboorhood at logon time and terminate it at logoff.
> This allows us to avoid UID/GID exporting problem at all, since it will
> be obvious which user's credetials to use for mount.
>
> Any objections?

Sure, you can have the mount installed at login time using pam or
similar. However, note that you'll have to verify that it works for all
login methods (desktop / telnet / ssh / ...).  Also, I don't know off
hand if you can properly detect whether someone has logged out other
than by polling utmp with a daemon.

I still think having all the homedir's automounted is a simpler
approach, even if they reside locally, if only because:

- - it will make adding users with homedir's in other places easier in the
long run.
- - all the expiry stuff is handled for you already.

It's up to you how you set it up in the end.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAyJOBdQs4kOxk3/MRAsdyAJ9Dte6QQbTZGczArGHCmZ6lGTfgpQCfSAaL
6gzr/hqZtIzI5e8u/0KYYRk=
=dEOW
-----END PGP SIGNATURE-----