Roland,
In unix land it is not so uncommon to rely on the filesystem. For
example, fetchmail uses a .fetchmailrc file in the users' home directory
and contains the usernames and matching passwords for all mail (s)he
wants to retrieve. Fetchmail actually refuses to work if this file has
the wrong permissions.
In your situation I also don't understand the problem.
If samba exports the homes, then the user logged into windows can access
only his own home directory. If it is different, I'd say samba can be
reconfigured to provide the proper protection.
Something like this should do the trick in smb.conf (from the example
configuration):
[homes]
comment = Home Directories
browseable = no
writable = yes
valid users = %S
create mode = 0664
directory mode = 0775
-- Jan Evert
Roland Schwingel wrote:
>
>
>
> Hi David and List....
>
>
>>Which mechanism of 'encryption' would you suggest? rot13? base64
>
> encoding?
> Well an encryption which at its best can only be read by svn client to
> decode it back in clear to send it to apache. I know that someone capable
> enough to program can extract the algorithm out of the sources and decrypt
> the password by then. The 'encryption' should be strong enough to hide the
> real password from human eyes by just opening a file in the editor,
> especially when your authentication mechanism you use in apache reads users
> data from a global authentification mechanism where you only have one
> unique password for everything. If it is detectable by just knowing where
> to find a single file the whole security is gone.
>
>
>>My suggestion is to rely on filesystem-level security to protect the
>>password files. If you want to defend against really stupid attackers
>>who don't know how to do google searches, promote base64 - this is what
>>the vast majority of 'encrypted' passwords for network-enabled apps are,
>>because they still have to 'decrypt' to plaintext. If you cannot rely on
>>filesystem-level security, don't store passwords to disk.
>
> In my eyes you cannot rely on that... Eg (like here) you have a linux box
> with the users homeaccounts and samba to share the filesystem to the
> clients and you use subversion on cygwin you are running very fast in
> exactly this situation. The auth and/or .subversion folder and their
> contents created by svn have 755 permissions on the linux box, so everyone
> can read them (This is a cygwin<->samba problem). You need to chmod at
> least the auth folder from the linux machine to protect the password.
> But even you imagine the fs level security is working, this will not
> "defend" a user who has root-access to the machine. He can read the file
> regardlessly of the permissions and so can get the cleartext password,
> which is elsewise completely hidden to him. When it is encrpyted in some
> way the burden to him to get it cleartext is much higher. I still suggest
> to encrypt the stored passwords, even I can understand your (David) points.
>
>
>>(Sorry if this came off as a rant, this same thread has come up three
>>times now this week on different mailing lists I subscribe to. Believe
>>it or not, I edited this post down... twice.)
>
> Ooops.. I just browsed very fast over the subversion users mailinglist and
> couldn't find an appropriate thread. Didn't want to hit a wound point.
>
> Roland, who is not wanting to start an ideologic war here, just noticing a
> (in my eyes) security design flaw.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 19 11:41:37 2003