On Sat, 2020-12-26 at 21:54 +0100, Jelle de Jong wrote:
> Hello everbody,
>
> I got the following autofs mapping example:
>
> /mnt/org/home /etc/auto.home --timeout=0
>
> *
> -fstype=cifs,sec=krb5,uid=${UID},gid=${UID},cruid=${UID},file_mode=06
> 60,dir_mode=0770,echo_interval=12
> ://samba.example.lan/users/&
>
> //samba.example.lan/users/<username> is on the server so
> //samba.example.lan/users/& works fine, however I got other shares
> that
> I want to mount and only accessable per user basis (securiy
> permissions)
>
> /mnt/org/documents /etc/auto.documents --timeout=0
> *
> -fstype=cifs,sec=krb5,uid=${UID},gid=${UID},cruid=${UID},file_mode=06
> 60,dir_mode=0770,echo_interval=12
> ://samba01.bothends.lan/documents
>
> This mapping does works and it mounts the document share as
> /mnt/org/documents/<username> however it also mount
> /mnt/org/documents/.hidden and tries to mount as root and all the
> other
> lookups in /mnt/org/documents will get a mount because the catchall
> *
> and no matching & limit in the shrae path. It becomes a mess.
>
> I have searched the manuals and I can not find a mapping system
> without
> & in the file path I want the * to match the user name so only that
> lookup with the username will be mounted.
>
> & -fstype=cifs ://samba01.bothends.lan/documents
> $USER -fstype=cifs ://samba01.bothends.lan/documents
I don't understand how this would work, explain please?
Also, don't forget people may use their maps in environments
that have OSes other than Linux and things like ${USER} would
make those clients fail.
>
> Something like this. How can I do this witout hardcoding the
> usernames
> mount points? If this functionality is not supported would it be
> possible to have * be replaced with a variable or some more dynamic
> feature? Tips?
The problem with using the wildcard map key is that, as you have seen,
it will match any request sent from the kernel. And the kernel doesn't
know if if the request is valid or not so it's bound to send it to the
automount daemon for it to work that out.
It wasn't a problem until software, usually GUI software, started
trying to access directories in the parent of the requested path.
There is no variable substitution or patten matching in the key part
of a map entry. Patten matching would make things very difficult.
I have been thinking about the implications of allowing variable
substitution there.
There are problems with that though, such as how can you be sure
of what is used for ${USER}, the automount daemon doesn't know?
The kernel only knows the user id of the process that triggered
the mount which might not be the user id that you expect.
For example suppose process 1, the user you want a mount for walks
on the path you want mounted, and suppose process 2, also attempts
to access that path at the same time and it gets to the point in
the kernel that initiates the request before process 1.
Assuming the mount is carried out and succeeds, then at least one
of these processes will get an incorrect result.
There's nothing that can be done to help with this.
These unexpected requests will be sent to the daemon, there's nothing
that can be done about that, but IIUC there are only a few of those
invalid paths, like .hidden, so perhaps some mechanism to add a list
of invalid map keys could be implemented ... I'm thinking about what
that would mean ...
Ian
