[Samba] Re: Authentication Question; WAS: installing Samba as non-root user

[Ryan Novosielski]

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



spamreceptacle at gmail.com wrote:
> See comments below.
> 
> On 9/26/07, Adam Tauno Williams <adamtaunowilliams at gmail.com> wrote:
>>
>>> Considering I am running this daemon as a non-root user, I am not sure
>> how
>>> this works, or if it's even possible.  I had another user map her home
>>> directory by tunneling to my server, and it worked, however she did not
>> have
>>> write access to her home directory.  I have added her as a Samba user,
>> using
>>> smbpasswd.
>>> Again, it's not clear to me how the authentication is actually
>> happening,
>>
>> Samba authentication and behavior are VERY well documented - RTFM.
> 
> 
> It's amazing how indignant people get when they think someone hasn't done
> his homework.  I've read the man pages in depth, and the official HOWTO.
> Unless I overlooked something, no where does it explain the authentication
> in the kind of detail that is necessary to understand if there's a way to
> have multiple users have proper access to their home directories when the
> daemon is not being run as root.
>
>> even if I were to be running the daemon as root.  Since you can add a
>> Samba
>>> user with smbpasswd with a password other than their Linux or Unix
>> password,
>>> how is it truly authenticating the user?
>> Not "can add a Samba user with smbpasswd", *must* "add a Samba user with
>> smbpasswd".  That password is used for authenticating users,  and unless
>> you are using some kind of mapping there must be a correspondingly named
>> user available from NSS.  All this is explained in the manual.
>  
> Of course I know this.  But I was simpling stating that the Samba password
> need not be the same as the Unix pasword (hence the use of the word
> "can"..."with a password other than").  This is VERY simple English - LTFL
> (learn the language).  And even your statement is not true, as you can use
> unencrypted password authentication which will authenticate via traditional
> Unix /etc/passwd, bypassing the need of smbpasswd.  All this is explained in
> the manual.
>
>>   In the case of running the daemon
>>> as root, are all actions done by root on behalf of the actual user?  But
>> it
>>> appears, per the smb.conf man page, that upon every Samba connection, a
>> new
>>> daemon is spawned for the user of the client that established that
>>> connection.  It would then seem that all share accesses are being made
>> by
>>> the actual user, as it should be, rather than through root.
>> A non-root Samba probably can't change it's own privileges or effective
>> user id.  This is one of the many reasons your configuration will not
>> work.  Samba must run as root or your going to have to jump through
>> endless machinations.
>  
> Yeah, unfortunately I was hoping that by going to the unencrypted password
> authentication that other users would have full access to their respective
> home directories.  Afterall, the authentication did in fact work for other
> users, despite the smbd daemon running as non-root.  I was hoping that the
> subsequent daemon processes that are spawned as a result of another user's
> connection, would be run as that user.  But they were run as me, which makes
> it obvious how they would not have write access to their files.  This makes
> it clear that the assumption is that smbd is run as root, and that allowed
> access is done by root on behalf of the user (or that by running smbd as
> root, this allows subsequent daemons to be run as the user who established
> the connection).

That is correct. If you run a daemon as you, it does not matter whether
the other users can authenticate or not -- they will still be unable to
read/write anyplace other than your files (which makes me think,
actually, that they'll probably be able to read/write your files even if
they're logged in as themselves).

The sysadmin in me makes me wonder why you can't just ask your sysadmin
to run Samba for you? Unless it is against a policy, in which case,
should you really be doing this anyway? :) Seems to me something like
SftpDrive (http://www.sftpdrive.com/) would be a better solution for
you. Even, honestly, using the GUI SFTP program that is part of the
Windows SSH client is just about the same thing, with the exception that
you don't get a drive letter (which I'm not convinced personally is a
great advantage).

- --
 ---- _  _ _  _ ___  _  _  _
 |Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Systems Programmer II
 |$&| |__| |  | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922)
 \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+rgNmb+gadEcsb4RAkrJAJ0eDRvUVrSIACSCI9Kvqzn8c3JpmgCfcQ4D
cU1V/bDUjZdliX/WzPgWM3Y=
=WNsH
-----END PGP SIGNATURE-----