From: Jan E. <je...@co...> - 2007-06-24 10:40:40
|
On Jun 24 2007 11:51, Werner Baumann wrote: > 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? What do I knew why users need davfs. Perhaps something like https://ourwebserver.company.com/. > 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. But people take it like one. https://mediacenter.gmx.de/ is supposed to do DAV. > 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. No news here, VFAT has similar limitations. >> 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. That's not my decision, users want it that way. They like SSO and single passwords. (All hard to remember!) And I'd rather much prefer having the same pw on the login box as the DAV server, so as to not keep _additional_ secret phrases _on the filesystem_. > 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. They have to treat both cases, because they _cannot_ know. That said, some even have to cope with additional cases like \r\n$ (Windows), in which case ne_strdup(... - 1) is wrong again. Jan -- |