Paranoid Penguin - Samba Security, Part III
Now that the SUPPER share is configured and available, it should start showing up in the Network Neighborhood (or other Windows network browser) of users connected to the LAN. Your Samba server, which we've configured to be a Browse Master for its workgroup, achieves this by sending out broadcasts.
However, in my experience, network browsers are often unreliable—it can take a while for your new workgroup, servers and shares to show up, and sometimes things disappear for no apparent reason. (Even for Windows clients, using the Map Network Drive feature to specify your share's path is both faster and more reliable than using the Network Neighborhood browser.)
So although you might get decent results testing your new share by simply firing up a network browser, I recommend using Samba's command-line tools instead, namely, smbclient and smbtree, which are included in Debian and Ubuntu's smbclient package, and in Red Hat and SUSE's samba-client package. I'll leave it to you to explore the smbtree(1) and smbclient(1) man pages, but I will give you a couple usage examples.
smbtree is a text-based Windows network browser that sometimes performs better than GUI-based browsers. To view all available workgroups, servers and public shares on your local LAN, use this command:
bash-$ smbtree -N -b
smbclient is a much more versatile command that can be used both to view and use Samba shares. To use smbclient to connect to our new share as the user nobody (guest), you can type:
bash-$ smbclient //CASA_DE_MICK/SUPPER -U nobody
Note the share-name syntax: //<servername>/<sharename>. You can use an IP address instead of the actual server name; this can result in a quicker login, because it allows smbclient to skip the name-resolution step. (Have I mentioned lately how inefficient the SMB/CIFS protocol is?)
Note also that to test the Bad User (guest-failover) behavior I described earlier, this command should be functionally equivalent to the previous one:
bash-$ smbclient //CASA_DE_MICK/SUPPER -U totallyfakeusername
You'll be prompted for a password. Simply press Enter without typing one (your nobody account shouldn't have a password!). If everything is working, you should see something like this:
Anonymous login successful Domain=[FED-CENTRAL] OS=[Unix] Server=[Samba 3.0.28a] smb: \>
At this point, you now have the Samba equivalent of an FTP shell—in fact, this environment is designed to be similar to FTP clients. To see a list of all available commands, you can enter ? or help. For now, we'll just do a quick directory by entering dir:
smb: \> dir . D 0 Tue Oct 7 13:22:28 2008 .. D 0 Tue Oct 7 13:21:16 2008 0-mon_filetmingon.txt 51 Mon Oct 6 21:05:34 2008 1-tues_gruel.txt 47 Tue Oct 7 13:05:54 2008 2-wed_beefmushcasserole.txt 5 Tue Oct 7 13:06:32 2008 52008 blocks of size 262144. 13782 blocks available
I'll leave it to you to figure out how to test copying files in both directions (put should work only for the user mick, but everyone else, including guests, should be able to list, get and read files).
On the strength of our SUPPER-creating experience, you'll find it fast and easy to create the group-readable share CHORES (which will contain lists of household tasks my boarders can perform in exchange for a rent discount). This share will be very similar to SUPPER: mick will have read and write access; pepe, skippy and knute will have read access only. However, unlike SUPPER, guest access will not be permitted.
Accordingly, after typing a new share name (CHORES) into the Create Share field and then clicking the Create Share button, we'll need to be sure to leave guest ok set to its default value of no. We'll set comment and path to Chore lists and /home/mick/chores, respectively (having first created this directory in a terminal window, and setting its ownership and permissions to be the same as for /home/mick/supper).
hosts allow and hosts deny can be the same as for SUPPER. browseable can be left at yes, but available should be left at no for now.
Figure 4 shows these settings (except available) for our new CHORES share.
Now, we'll switch to Swat's advanced view for this share (if you aren't there already) by clicking the Advanced button. As with SUPPER, we'll blank out admin users, because we're paranoid, and also read users, as read only already is set to yes.
As you can see in Figure 5, however, I'm employing a bit of useful laziness in the valid users field for CHORES.
In the valid users field in Figure 5, the + in front of users instructs Samba to look up the name users in /etc/group, and then replace this entire value with a list of all members of the group users. Because on this server that group consists of mick, knute, pepe and skippy, Samba ultimately will set the value of valid users to mick, knute, pepe, skippy.
Needless to say, be careful with group names in this context. Before using one in Swat (or directly in smb.conf), be sure you know for certain exactly which user accounts belong to that group.
The quickest way to do this is to look up the group name in /etc/group and note its numeric value, noting also any secondary group members it has. Then, see which users in /etc/passwd have that group's number listed as its primary group.
Here's how this looks when enumerating the group users on my Ubuntu system:
mick@ubuntu@:~$ grep users /etc/group users:x:100: mick@ubuntu:~$ grep :100: /etc/passwd dhcp:x:100:101::/nonexistent:/bin/false mick:x:1003:100:Mick Bauer:/home/mick:/bin/sh knute:x:1004:100:Knute:/home/knute:/bin/sh pepe:x:1005:100:Pepe:/home/pepe:/bin/sh skippy:x:1006:100:Skippy:/home/skippy:/bin/sh
As you can see, there are no secondary users listed at the end of the user's entry in /etc/group. My second grep command turned up five users, not the four I was expecting, but dhcp matched only because its numeric user ID (not its group ID) is 100.
The other settings we should change are create mask, which we'll again set to 0644, and then browseable, which we now can safely change to yes. Finally, we can click the Commit Changes button, and CHORES is ready to go. Preferably using another system, test it to make sure it works the way you expect.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Validate an E-Mail Address with PHP, the Right Way
- Weechat, Irssi's Little Brother
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Reply to comment | Linux Journal
40 min 40 sec ago
- Welcome to 1998
1 hour 29 min ago
- notifier shortcomings
1 hour 52 min ago
3 hours 29 min ago
- Android User
3 hours 31 min ago
- Reply to comment | Linux Journal
5 hours 24 min ago
8 hours 13 min ago
- This is a good post. This
13 hours 26 min ago
- Great, This is really amazing
13 hours 28 min ago
- These posts are really good
13 hours 30 min ago
Free Webinar: Hadoop
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?