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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)