From: Werner B. <wer...@on...> - 2007-06-24 09:51:45
|
Jan Engelhardt wrote: > Users wanting to use pam_mount with davfs2 know that their regular > PAM password will be used for any mounting. Hence, they have their > webdav one set accordingly. I would not give away the login password to the administrator of some WebDAV server I don't even know. So what kind of WebDAV server are you talking about? Let me guess: some administrator installs a WebDAV server in the LAN as replacement for NFS or CIFS? But note: davfs2 is not intended as a network file system like NFS or CIFS and is not suitable for this. A WebDAV server is not a file server. The WebDAV protocol does not match the file system interface. davfs2 *tries* to map a WebDAV-resource into a file system. But there is no 1:1-mapping, some tweaking and faking is necessary and there will always be some shortcomings. Thats why it seems very impropable to me, that one reasonable has the same password for login and for WebDAV-access. > Users cannot edit the files in /etc/davfs2. Users can't edit the pam_mount configuration files either (I hope so!). The administrator has to set up this for the user, including credentials. So you want root to mount a WebDAV-resource on behalf of the user, but you don't like to tell root the WebDAV credentials. You prefer to tell your login password to the WebDAV administrator instead. I would prefer it the other way round. A possible solution might be: davfs2 allows root to configure a different secrets file in /etc/davfs2/davfs2.conf. This may be different for every mount-point and the secrets file can be under control of the owning user. Currently this is not possible, but it would be an easy change. I will have to think about any security related implications of this. > Right... I am referring to > samba-3.0.25a/source/client/mount.cifs.c:get_password_from_file(). > Apparently, it allows for an \n to be present, but it is known to > also accept input that is just the bare password without any \n. > > util-linux-2.12r+git20070530/mount/lomount.c:xgetpass() does the same > (accepting either \n or no \n). The 'protocol' is described in > mount(8), though it does not say anything special about newline in > single-key mode. O.k. 'established protocol' means 'some others do it also'. I agree that davfs2 should check any input for errors or non-standard behaviour. But, as you are redirecting standard input, you might as well delimit your input with a newline character, instead of trusting on davfs2 to check for this. I am not sure, whether it is really o.k. to treat a missing newline *always* as lazy programming and *not* as an input *error*. But I am sure: all applications that read from stdin are able to treat with a trailing newline, because this is what they usally get. > Don't worry too much about that. lomount also uses getpass :-/ As I understand (I did not test it), getpass() will block, if it finds a real terminal but there is no input from this terminal. lomount only uses getpass when it is sure that the input will come from a terminal. So I think I should change this. Cheers Werner |