Prev: What to expect with out-of-sync RAID devices?
Next: SQUID problem;need help
From: HASM on 3 Feb 2010 15:24
Nico Kadel-Garcia <nkadel(a)gmail.com> writes:


> Are the directories mounting as designated users, or are they mounting
> all as the same generic user (which seems the only way to do it without
> CIFS credentials provided in a text file or via other means.)

They mount as the user, via a credentials file. Simultaneous mounts by two
users will need some mods to the stuff below.

> Can you send me an example of your cifs setup for autofs, because the
> default tables don't include it.

Add a line like this to /etc/auto.master:

/smb /etc/auto.smb.top --timeout=120

Create a one liner /etc/auto.smb.top like:

* -fstype=autofs,-Dhost=& file:/etc/auto.smb.sub

Create a one liner /etc/auto.smb.sub like:

* -fstype=cifs,credentials=${HOME}/.credentials,uid=${UID},gid=${GID} ://${host}/&

Create ${HOME}/.credentials for the user that will do the automount with

username=windows_user_name
password=password_for_that_user

Make sure to make it unreadable by anyone but you (or root :-)) Or use
a common .credentials file for a guest user.

Then that user can simply "cd /smb/<host>/<share>" and it should work, .e.g
cd /smb/laptop/c or cd /smb/laptop/'C$' Works for me ...

I had trouble with earlier versions of CIFS with machines that were
rebooted while the mount existed, but it seems to be fixed now (since
Fedora 10 or 11? I'm now on 12)

-- HASM
From: Nico Kadel-Garcia on 3 Feb 2010 19:51
On Feb 3, 3:24 pm, HASM <netn...(a)invalid.com> wrote:

> Create ${HOME}/.credentials for the user that will do the automount with
>
> username=windows_user_name
> password=password_for_that_user

No.
No.
No.
No.

Did I remember to mention "No"?

If you do something this foolish, you've just succeeded in recording
your Windows login name and password where anyone with access to your
backup tapes, NFS access to your home directory, or for whom you've
stepped away from your locked in session ot steal your passwords. I
can't overemphasize how bad this practice is: While it's been common
in CVS and Subversion for years, it's still amazingly stupid.

Worse, if that careless SMB mounting person has "sudo" privileges,
you've just given away root access. If you *HAVE* to do this, at least
restrict it to root owned files stashed somewhere in /var/, not in
your $HOME location.

The reason I was looking at pam_mount was precisely to get away from
this sort of foolishness.
From: HASM on 4 Feb 2010 09:40
Nico Kadel-Garcia <nkadel(a)gmail.com> writes:

>> username=windows_user_name
>> password=password_for_that_user
>
> No.
> No.
> No.
> No.

Sure, but ... there isn't another linux/unix user in sight around here that
would know what to do, believe me, no one else has a logon on that machine,
and, more importantly, the name/passwd above is NOT my windows
login/password but a special windows domain user with mostly read only
access to most shares I care for and write access to public stuff anyway,
i.e. everyone around here knows that username/password.

-- HASM

From: J.B. Wood on 4 Feb 2010 11:52
On 1/31/2010 11:51 AM, Nico Kadel-Garcia wrote:
> I'm looking at some requests for auto-mounting of CIFS at work.
> pam_mount seems well designed to do just this, but there seems to be
> real RPM hell of backporting it from any actively supported version of
> Fedora: it looks like even for Fedora 10, it's dependent on XML
> support in PAM. And since the codebase for RHEL 5 is now 3 years old,
> with no sign of even a beta release of RHEL 6 on the way, it looks
> like I'd have to go through RPM hell to backport it.
>
> Does anyone have a working pam_mount for RHEL 5 that they can point me
> to? It might even be worth some consulting money to get a copy of it.
> I'm working as a consultant right now, and really don't want to blow a
> month of consulting time to provide something that I'm not even sure
> is feasible on such an old code base.
Test
First  |  Prev  | 
Pages: 1 2
Prev: What to expect with out-of-sync RAID devices?
Next: SQUID problem;need help