public Samba SMB shares cannot be accessed anonymously from Windows XP, a password prompt appears

Ubuntu and gnome have a "Just Works TM" philosophy in everything and this seems like a no brainer win-win fix. The samba package is not installed nor are any file shares enabled by default. Comitting this small change would allow samba to work easily without frustrating newbies and clogging up the IRC channel.

This is definitely not the right fix. security=share is insecure by nature, and is begging users to do rather painfully bad things to their own setup.

If the smbpasswd entry isn't being created when you create a new share in GNOME (I thought this was working in breezy, but maybe I'm misremembering this here), that needs to be fixed to work.

Adam, could you please post a reason of why security=share is insecure? This seems to be the only way to communicate between shares between Windows and Linux.

It's certainly not the "only way." In the default setup, if you just invoke "smbpassd -a [yourusername]" as root (ie: with sudo or from a root shell), you an connect to samba just fine as your user.

I'm trying to dig up the upstream docs on why security=share was considered a bad idea originally, but the one that pops up off the top of my head is that with security=share, you end up with Samba (running as root) randomly trying the passwords you provide it against a guessed list of UNIX account names, which means samba can open up your box to rapid-fire dictionary attacks.

The other thing (not security related, of course) to mention is that samba in pretty much any installation except for this specific task (GNOME user wanting to share files easily) would almost always be secured with security=user (or some domain scheme), as it allows more fine-grained controls.

The fact that I've never run a Samba server with security=share, but have always run Samba servers specifically for Windows clients to connect to them makes it failry obvious that "security=share" isn't required to share files with Windows, however.

It's a wish so i change severity.
The problem is "Shared folders requires a login" see #22611

Adam, what is the way to do an "anonymous share" so? Many users are used to simply share a directory that everybody on their LAN can browse

The real issue here is, that

;security = user

is not achieving anything at all, since security = user is a Samba built in default, commenting it out would be the solution if it wasn't there already. So either you use

;security = share

which is the same as

security = user

or just uncommented as

security = share

when you want to share.

The problem lies in the fact, that not all Windows users will have an account on the Linux workstation sharing something.

They can only access the share with

security = share

There is a realtively thorough discussion in the man smb.conf, also some workarounds are given.

If you want to see what your smb.conf REALLY is translated into, just do

testparm -v

if you do this with an empty smb.conf you can see what defaults are there already.

In addition having

   invalid users = root

is a real show stopper and should be commented out in the sample file. If this is set,

cupsaddsmb

( and presumably other functionality as well ) will not work, and present the average user with a problem he will not be able to solve easily. At least there should be some remarks on this.

Hi,

Is there any progress on this subject? Samba folder sharing still does not work out-of-the-box. The first time I ran into this, it took me over two hours to find out that I had to add a user with smbpasswd -a, and I'm not exactly a linux newbie either.
Maybe it would be good to have smbpasswd -a being executed automatically the first time you share a folder from Gnome, perhaps using a little dialog window. Or maybe setup automatic linux-samba user synchronization?

Thanks for your support.
cheers Bart.

Using the "net usershare" feature from new samba and nautilus-share could be a nice way to fix that

This "need a GUI for smbpassword" problem was mentionned in Andew Thomas's review of Ubuntu on the British site "The Inquirer" a few days ago; the _apparent_ lack of interoperability with his Windos macines made him ditch Ubuntu sadly. I remember being extremely confused by this when first using Ubuntu as well, so this is might need more priority IMO. I don't think the fact that it's Vista and Samba having problems since those were fixed in January, but the smb-password no GUI problem. http://www.theinquirer.net/default.aspx?article=37742

"....But I wasn't installing it on a notebook, it's on a desktop machine sharing a LAN with two XP and one Vista boxes. Vista and XP play happily together, doing all the file and printer sharing I need with absolutely no bother. The Ubuntu PC is a different matter entirely. I was advised, by friends who swear by Linux and at Microsoft, that I needed to install Samba, which I duly did. I am assured that Samba's sole purpose in life is to enable Linux and Windows machines to co-exist and cooperate on the same LAN.

Well, I've only been playing with computers since 1972 and I couldn't make it work. Linux can see the Windows boxes and vice versa, but any attempt to access files is met with a login dialogue box that refuses any username and password I enter. Now my learned friends tell me I should be using something called Wine. I've been a heavy user of wine for many years and it certainly helped relax me but did absolutely nothing for my connectivity dilemma.

So I've done what any normal person would do in the circumstances – give up. If the awfully-clever people who write bits of open source code can't make it work automatically, I stand absolutely no chance of fixing it. It looks very much to me as if people clever enough to write an entire operating system can't make a simple bit of networking work, it has to be a deliberate marketing decision rather than a lack of ability."

I very much agree. It's one of the first things you do on a computer: look on the network and see what's connected.
I remember thinking that anyone looking at ubuntu for the first time and trying this out would be very very disappointed that this does not work out-of-the-box. And I'm also very sure that no one except a linux nerd like myself, would get it to work.

How can we raise priority?

regards Bart.

The title of this bug should be changed too I guess. I don't know if this is the way it should be done, but I will try to change it to "Need Access Options on Samba Share Folder Dialog".

We need an interface when sharing a folder that somehow points the user to adding a samba user.
I would think:

+---------------------------------------------------+
| Path : /home/myuser/myFolderToShare |
| Share through: Windows networks (SMB) |
| Access : [ ] Everyone (read only) |
| [ ] Linux users and rights |
| > [advanced] |
+---------------------------------------------------+

Button [advanced] goes to a more advanced screen to setup samba users.

regards Bart.

Hello Bart, All,

this thing is over one year old now. As you can see by the heading:

Affects Status Importance Assigned To
samba (Ubuntu) Unconfirmed Wishlist —

it is not confirmed ( !!! ) has no importance and is not even assigned to anybody.

I think the best you can do, is try a shot upstream at gnome.org or samba.org, this problem is true for all distros I tried so far. Only Fedora had some GUI approach for this, alas it did not work for me ( FC6 )

In addition it is also a problem for cups and ldap as far as my experience goes. The best place to solve the issue in my view would be user management, where you could add for which product this user should be registered ( Samba, Cups, LDAP, etc. )

Casual

How difficult would it be to modify folder-shares to look like this?

http://img360.imageshack.us/img360/8206/pantallazocarpetascompaqd0.png

This looks perfect to me.

On 3/14/07, David Prieto <email address hidden> wrote:
>
> How difficult would it be to modify folder-shares to look like this?
>
> http://img360.imageshack.us/img360/8206/pantallazocarpetascompaqd0.png
>
> --
> the security parameter must be set to share, not user, in smb.conf
> https://launchpad.net/bugs/32067
>

Is there anyway that Ubuntu could automatically add an SMB user when you first share a folder? I can just imagine people still coming on ubuntuforums saying that sharing doesn't work, and we'd have to point them to create an SMB user first, so there's not really much difference than having to do the command line bit after expecting to be done with an action (although I agree a GUI is better than nothing). Or maybe a first time setup wizard for Samba with smbpassword in mind?

It's too bad "security=share" and "encrypt passwords=no" is so insecure b/c it's very convenient and what Windows users are used to.

I've become so desperate with the state of local file sharing that I actually discovered "gshare", which is a built-in FTP using Avahi. Works perfectly, and no headaches. Of course this is no solution for samba, it's just a workaround in the meantime: http://yimports.com/~cpinto/projects/gnome/gshare/

I just have a question; this bug is now "confirmed", but shouldn't it be assigned to someone specifically or at least "Ubuntu Desktop Bugs", as a lot of other bugs seem to be? It just looks weird to me that the "assigned to" is empty.

the assignment is usually using when somebody is working on a bug, there is no team working on samba at the moment though

OK, thanks for replying Sebastien.

I guess I'll just post this here as well, it's a Samba GUI Replacement that has been spec'd in Launchpad and on the Wiki, and it has some screenshots as well which ties into the first-time wizard, but it does need a GUI for setting up users like the one that David posted. But I wonder if it's better to put in the GNOME User Manager or a Samba user manager.

Ubuntu Wiki entry: https://wiki.ubuntu.com/GUISambaConfigSpec
Launchpad Specification Entry: https://launchpad.net/distros/ubuntu/+spec/samba-config-gui

https://wiki.ubuntu.com/GUISambaConfigSpec?action=AttachFile&do=get&target=wizard1.png
https://wiki.ubuntu.com/GUISambaConfigSpec?action=AttachFile&do=get&target=wizard2.png
https://wiki.ubuntu.com/GUISambaConfigSpec?action=AttachFile&do=get&target=wizard3.png
https://wiki.ubuntu.com/GUISambaConfigSpec?action=AttachFile&do=get&target=wizard4.png
https://wiki.ubuntu.com/GUISambaConfigSpec?action=AttachFile&do=get&target=wizard5.png
https://wiki.ubuntu.com/GUISambaConfigSpec?action=AttachFile&do=get&target=samba-config-editor-main.png

I'm kinda new at all this, and - I must say - have been experiencing my share of frustration with getting things to work: Samba being no exception. Whilst perhaps a GUI might be a good solution, I think a straight-forward, do-this,-then-do-that type of tutorial - unencumbered by the history of SMB and the future of Microsoft or the vagaries of the whole OSI thingie - would make me happy enough to where I could forgo the GUI. Give me one really good example, some sample lines of code to copy and past into a file or into the terminal that actually works... hey, that would work for ME!

I certainly don't expect - or even *want* - Linux to be like Windows... I just want it to work, and I realize that in order for it to work, there's some stuff I need to understand... so I want explanations that make sense to me. I feel that in that way, it will help me become better acquainted with this brilliant piece of work called Linux.

Just wanted to add another GUI example of adding Samba password; this is from OS X TIger 10.4.8 just for exhibiting purposes. OS X also requires a Samba password to share files. I like this better than the Red Hat system config tool for samba, because it shows that you must have *nix user account already created in order for you to create a Samba password for them.

The obvious, simple solution is to automatically add the user via smbpasswd -a to duplicate the unix user name. The problem lies in the password. Since it is hashed, the system can't just reverse the hash, get the password, and add it to the samba user database.

A complete solution might be found with the pam_smbpass module, which keeps the samba password database in sync with /etc/passwd
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/pam.html#id424060

1. I'm working on getting redhat-config-samba into Ubuntu
2. The SimpleSamba spec should also make this problem a great deal smaller.

Just uploaded system-config-samba to gutsy. It'll show up within a week, I think.

I don't see any system-config-samba in the repo's?

It got delayed, I'm afraid. It's there now.

Does the (almost) finished application still list "Windows 95/98" and "Windows NT/2000" as security levels? Win2000 can certainly get to Win98 shaes, so this is misleading.

SO, we can apt-get install system-config-samba .. but users still need to know they have to do this before they can make samba work?

What is the current plan of attack on this bug? Are the passwords of samba automatically synced with pam now?
That would be perfect!

Another plan of attack would be:
  - make sure the default file permissions are 750/640
  - enable sharing by default (or make it a one-flip switch)
  - put samba security on 'share'

This was a user can share files just by changing the permissions of their files.
This would be the most obvious for the end-user.

I thought share-level security mode was bad for security. Why not use user-level?

user-level is the default setting and it should be kept that way.

Bug 128548 has a fix to enable net usershare, which could be used with with nautilus-share extension as suggested by seb in above (https://bugs.launchpad.net/ubuntu/+source/samba/+bug/32067/comments/9).

However it won't be implemented for Gutsy as we're in FeatureFreeze. It'll have to wait for hardy.

Regular users need to know be able to enable share-level security somehow, without having to know what /etc/samba/smb.conf is.

It would be fine to have user-level security -- if samba uses PAM, and users of a particular group (which desktop users are members of by default) are automatically included as samba users.

Then, you try to connect to your machine, and it asks for a password. You give the password. That gives you access to the share.

This wouldn't require new software, it could be done through configuring the software that's already there. While not as good as giving secure defaults and the freedom to be stupid if they like, it's still decent.

Also, it would be nice, at some point in time, to have some sort of limited-access share (Not homedir, not below homedir unless in 'media', + warnings on granting write access).

system-config-samba is provided in gutsy in a usable condition. It supports setting the security level to share. Perhaps a nautilus plugin similar to nautilus-share can be written that interfaces with system-config-samba and it can be included by default instead of nautilus-share.

I think the config is set to share on my system, and when I try to
connect locally I have no problems, but if another system (xp) tries to
connect, it gets a user/pw dialog.

/* vaguely wonders if self just confused two bug threads, but too tired
to sort it out now */

Short-term solution for Gutsy:

1) samba is not installed by default, people explictely require this package to be installed. They want to share files. It should share files immideately after installing without requiring futher user interaction!

2) pam-backend keeps it secure, without forcing the user the use different passwords, or anything. We already have a user-management system, we don't need another one for each separate application.

3) printers should be shared without requiring a password! Windows doesn't seem to support connecting to samba-printers which have passwords. When you select 'share with everybody' in system-config-printer interface this should extent to everybody on samba.

(Future) tweaks of the pam-backend:
  - have a samba-users group
  - newly created users are automatically part of this specific group

The underlying problem is an architectual problem which scope is much bigger than just SAMBA.
- All user, group and permission management should be centralized and managed within one interface (PAM).
- Packages should not implement their own ad-hoc user-management ( i vote to just strip all that crap )
- This does not just concern samba, there are more packages that think they are special enough to need their own user-management. Like MySql server for example.

We need to get rid of this, because:
 - they are all incompatible
 - they are inconsistent with each other
 - they are too complex for average desktop users (requires too many configuration interface, half of which don't exist yet)
 - they are too much hassle for system administrators

I think somebody official should set out an official policy on to deal with this widespread growth of custom user-managent stuff. If PAM does not suffice for specific packages, they or we need to file bugs about PAM, rather than go with some custom user-management different for each application and service.

But that's just my two cents. Perhaps i'm missing somehting very obvious here...

There's no problem with setting the default level to share!

When you add a shared folder, you can have it read only. And the people having problem with editing smb.conf is probably home users not wanting any heavy security anyway. People needing security probably knows how to edit the config file.

At least a checkbox in shares-admin for setting the level to share would be nice to have.

>From what I understand, Share-level security basically leaves you open
to password brute force initiated by your own daemon.

No good.

On Sat, 2007-09-22 at 17:12 +0000, Anders Østerholt wrote:
> There's no problem with setting the default level to share!
>
> When you add a shared folder, you can have it read only. And the people
> having problem with editing smb.conf is probably home users not wanting
> any heavy security anyway. People needing security probably knows how to
> edit the config file.
>
> At least a checkbox in shares-admin for setting the level to share would
> be nice to have.
>
> ** Attachment added: "shares-admin mockup"
> http://launchpadlibrarian.net/9464149/Skjermdump-Shared%20Folders.png
>

Are you sure about that?

In samba log files I have "connect to service Music initially as user nobody"

And no other traces of login stuff. No password is supplied at any point.

I tried to look up the problem you describe, but there seems to be some misunderstandings about level share creates some compability problems.

I also tried supplying arbitary as well as valid usernames and passwords. Note that I have no samba users, I tried system users. None of these login attempts were successful.

I was only able to connect with blank username. Seems like passwords is newer read as no samba users are created. Supplying an unvalid password with blank username works fine.

I totally agree with Ralf here:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/32067/comments/36

I just tried system-config-samba and I didn't like it. It is basically a full dup of what already is present in Ubuntu:
 - The share list is a dupe of Administration / Shared Folders. That's where I want to set my shared folders, as it is integrated with nautilus too.
 - The user list is a dupe of Administration / Users and Gruops. There should be only one user list, please.

Basically, I believe that system-config-samba is a step in the wrong direction. Besides setting up PAM to keep samba synchronized (which is good), what we only need is a way to set user permissions in shares inside the "Shared Folders" app, and if an user without samba password is selected, a dialog should appear asking to type in the password (just like Mac does!) (and of course warn if it does not match the unix password).

I like that it lets you change security level.

Do you guys realize that this is going on since Feb 2006 ?
Do you have an idea why Ubuntu should be preferred over other distros ?
I don't. Sorry!

This really needs to be changed in Hardy. PAM synchronisation of users sounds like a great idea, and security=user should be enabled by default, so users do not unwittingly open themselves up to attack. However, the shared folders tool must provide an obvious option to allow anonymous access, as many users are used to this being the default behaviour when they share folders on windows.

Perhaps my situation is aberrant, but I live in a house with 3 housemates, all of whom have PCs. They each share their useful documents and media as read only folders on Windows XP. We have become very used to accessing each others computers to get at the file we want, usually a video or mp3. However, the method Ubuntu seems to suggest would require either creating my housemates user accounts on my PC, or allowing them access to my user name and password.

If Ubuntu had an easy-to-use option that mirrored the way windows shared folders, and provided the user a warning about security, it would make the whole OS a lot more usable for me.

@charlie

Yes, it seems the server-client model is one of the tunnel-visions of linux. It does not suit all areas and use-cases well.

Why not add an anonymous user? A guest user.
This user can log in, This user can access all publicly available files of all the other users on the system. This user can connect through samba without a password.

The difference with an ordinary user?
 - home directory is emptied at login & logout
 - sudo rights are not possible

Advantages to having such an account exist by default:
 - easy to temporarily work on another pc
 - a kiosk pc is created by just setting the autologin to this user
 - samba and other types of filesharing can be enabled out of the box

Caveats:
 - new files created by ordinary users should not be world-readable by default
 - it might be wise reword/simply the folder and file permissiosn dialog to just choose between:

    Private - Local - Public - Shared

Where private means only you can read/write.
Local means all real users on this machiene can read/write
Public means all users, including anonymous/guest can read
Shared means all users, including anonymous/guest can read/write

Maybe it would be nice to add a simple 'share public files with this user' option in pidgin as well.
This user could access the same files as the guest account could.

But that is not a bug-fix. That is a specification. Maybe i'll try to write out it out all.
It would fix this bug, and implement the easy-file-sharing spec, etc.

I have just a couple comments about this.

I think it would be great to have a more informative share gui. It can be very simple and have the ability to share will everyone (ie. no user or pass needed) just like windows xp when you just enable file sharing.

Then it can have a users tab for specific system or new smb users to be added per share.

I believe for the new users coming into the linux world that choose ubuntu this could be one of the reasons why they go ubuntu over the other distros. Where network file sharing just works OOTB.

So, whats the status of this bug in Hardy?

Is samba sharing still completely broken for those who are not system maintainers.
And if so, can we at least remove the 'shared folders' stuff from the default install.

It's confusing because it pretends something will work, when it does not.
And honestly, having users setup accounts is ridiculus. Either use pam or enable sharing by default.
For all purposes considered the local network can be expeced to be trust worthy.

Currently, the logic is:
  - the home is user is a linux guru and knows how to edit smb.conf
  - the professional system maintainance guy is an idiot and should be prevented from enabling samba-share easily in the hostile environment where they deploy, because they might not know what they are doing.

The logic should be:
  - the home is is not a linux guru and needs sharing to work by default, without any configuration.
  - the profession system maintaince guy knows what he is doing and he/will change the defaults it that is too insecure for his environment

Other than that, waiting for some magic GUI that still asks too many questions (i.e. more than one question), is just not acceptable. Until you have something that also 'protects' the profressiosnal system deployer, focus on the home user. Enable pam-backend or set security=share by default. Anything else borderlines on ridiculus academic dreamcastles.

I doubt anyone arguing that it's insecure is using the 'secured' setup by default and has working printer sharing. So, what's good enough for you, should be good enough for us. People just want this to work and are running it insecurely _right now_. It just took them more effort to figure out how to do it and it inforces the impression they should just copy & paste stuff from forums on the command-line. How else is Ubuntu going to work without copying and pasting random stuff from forums?

Fix this bug already. Let's not wait for some gui magic. Fix it until that gui is there. People are going to to configure it insecurely _anyway_. They just want to share files on their local network with their families.

My thoughts exactly. The default should be changed to share in a
home-oriented distribution like Ubuntu.

Use:
map to guest = Bad User
with:
security = user

I would say the best wey is to add:
map to guest = Bad User

why? because default settings of ubuntu smb.conf will allow user nobody
but will not allow any other user what not exist in /etc/passwd . With
nautilus this working because this has some workaround and it try to
login as $user and after it failed, will try to login as nobody or NULL.
windows xp do not do this second try. So we need to make it before.

See: man smb.conf
....
map to guest (G)
 ......
         Bad User - Means user logins with an invalid password are
         rejected, unless the username does not exist, in which case
         it is treated as a guest login and mapped into the guest
                   account.
.............
and
.....................
            SECURITY = USER

        This is the default security setting in Samba 3.0. With user-
        level security a client must first "log-on" with a valid user‐
        name and password (which can be mapped using the username map
        parameter). Encrypted passwords (see the encrypted passwords
        parameter) can also be used in this security mode. Parameters
        such as user and guest only if set are then applied and may
        change the UNIX user to use on this connection, but only after
        the user has been successfully authenticated.

Security will not be set to "share". It's an inherently insecure way to
be sharing files. Now that we both have net usershare and
system-config-samba, (I belive) there's already a spec about syncing
passwords between pam and samba, I fail to see the value of this bug
report being kept open anymore?

--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/

it may be inherently insecure, but it is the default on Windows - and Samba is meant for sharing files with windows, so I see much value in this bug open. If there is no desire to have security = share, I think there should be an easy way to enable it (and installing system-config-samba is not the way unless it is installed by default)

I'm sorry, but I really do see the value of this being kept open. I realise that this method is inherently insecure, but it seems people are ignoring the substantial use-case of a Ubuntu newbie who is used to sharing his files in Windows, and is faced with the near-labyrinthine configuration of users in samba, or setting security=share themselves.

I am also a OS X user, and it would seem the approach you suggest mirrors very closely how their sharing setup works. That, too, is a huge problem, as some people simply do not want their username and password to be given out, or have to set up a new user and password for everyone who wants to access a certain folder. If defaulting to a guess user would work, with absolutely no set-up required on either side, then I guess that would be a viable solution, but I don't see how that would work without first prompting a windows user for a username and password when they try and connect to the folder.

The installation process could ask some questions like "Do you want to
require a username and password to be entered when accessing this
computer's files over the network?"
User if yes, and share if no.
The "Shared Folders" applet should also allow you to change this EASILY.

@Soren

You said:
"Security will not be set to "share". It's an inherently insecure way to
be sharing files."

Soren, we can repeat this _over_ and _over_ again. There is nothing about security=share that is not exactly as the user would_ expect_ it to be when installing samba.

Use case:
The user wants to share files on his home-network with his family.
The user enables file-sharing, samba gets installed.
File-sharing does not work, because Soren things its unsafe to share files with your family.

At least give them a message telling them you know it's best for them to not share files with their family. Perphaps include a message about what to put in their sandwich or on which political party to vote.

Insecure means we share files with people we don't _want_ to share files. When we do want to share files, sharing files itself is not insecure.

Can this idiotic line of though now finally be abondended. Samba is *not* installed by default. We *enable* it ourself. By that we are _telling_ the system we want to share files. That would be the point where the 'its insecure, your wife might be a terrorist and shouldn't access your files' crap is not pleasing any one.

I agree and furthermore i think it would be good to warn them that it is insecure and to disable it as soon as possible if they go out of their home network and have an easy turn off file sharing setting.

On Tue, Jan 29, 2008 at 01:13:08PM -0000, Ralf Nieuwenhuijsen wrote:
> You said: "Security will not be set to "share". It's an inherently
> insecure way to be sharing files."

I did.

> Soren, we can repeat this _over_ and _over_ again. There is nothing
> about security=share that is not exactly as the user would_ expect_ it
> to be when installing samba.

Look... If you ask anyone who just converted from Windows to Ubuntu if
he/she thinks that his/her samba server should be set to security=share,
you'll get nothing more than a blank stare. They don't know what it
means, they don't care, and they *shouldn't* care!

Could you please try focusing on the problem rather than trying push the
wrong solution to said problem?

We want to make the process of sharing files on your network a) cause
the least amount of surprises, but b) without being a gaping security
hole.

There are several correct solutions (none of which involve
security=share). One of them could be to automagically sync Samba's
passwd database with the one on the system, so whenever someone tries to
connect to your share, they'll be asked for a username and password and
be able to user their usual user/pass combo rather than a completely
different set (which is currently the case). nautilus-share provides a
simple way of sharing folders to the network. Those two things put
together, and we win. IIRC, nautilus-share even allows you to allow
guest access, so you can make it as insecure as you (apparantly) want.

> Use case:
> The user wants to share files on his home-network with his family.
> The user enables file-sharing, samba gets installed.
> File-sharing does not work, because Soren things its unsafe to share files with your family.

If you're attempting to achieve a spot in my ignore filter, you're well
on your way.

Now, if you could please calm down and find a sensible tone for this
discussion, that would be lovely.

--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/

Users also need a way to turn off passwords (and make a glaring
security hole themselves), even if it's not the default.
But yes, the user/passwd database should DEFINITELY be synced.

On Jan 31, 2008 4:21 AM, Soren Hansen <email address hidden> wrote:
> On Tue, Jan 29, 2008 at 01:13:08PM -0000, Ralf Nieuwenhuijsen wrote:
> > You said: "Security will not be set to "share". It's an inherently
> > insecure way to be sharing files."
>
> I did.
>
> > Soren, we can repeat this _over_ and _over_ again. There is nothing
> > about security=share that is not exactly as the user would_ expect_ it
> > to be when installing samba.
>
> Look... If you ask anyone who just converted from Windows to Ubuntu if
> he/she thinks that his/her samba server should be set to security=share,
> you'll get nothing more than a blank stare. They don't know what it
> means, they don't care, and they *shouldn't* care!
>
> Could you please try focusing on the problem rather than trying push the
> wrong solution to said problem?
>
> We want to make the process of sharing files on your network a) cause
> the least amount of surprises, but b) without being a gaping security
> hole.
>
> There are several correct solutions (none of which involve
> security=share). One of them could be to automagically sync Samba's
> passwd database with the one on the system, so whenever someone tries to
> connect to your share, they'll be asked for a username and password and
> be able to user their usual user/pass combo rather than a completely
> different set (which is currently the case). nautilus-share provides a
> simple way of sharing folders to the network. Those two things put
> together, and we win. IIRC, nautilus-share even allows you to allow
> guest access, so you can make it as insecure as you (apparantly) want.
>
> > Use case:
> > The user wants to share files on his home-network with his family.
> > The user enables file-sharing, samba gets installed.
> > File-sharing does not work, because Soren things its unsafe to share files with your family.
>
> If you're attempting to achieve a spot in my ignore filter, you're well
> on your way.
>
> Now, if you could please calm down and find a sensible tone for this
> discussion, that would be lovely.
>
> --
> Soren Hansen
> Ubuntu Server Team
> http://www.ubuntu.com/
>
> --
>
> the security parameter must be set to share, not user, in smb.conf - Smb/Gnome sharing broken
> https://bugs.launchpad.net/bugs/32067
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On Jan 31, 2008 11:21 AM, Soren Hansen <email address hidden> wrote:

> Could you please try focusing on the problem rather than trying push the
> wrong solution to said problem?
>
> We want to make the process of sharing files on your network a) cause
> the least amount of surprises, but b) without being a gaping security
> hole.
>
> There are several correct solutions (none of which involve
> security=share). One of them could be to automagically sync Samba's
> passwd database with the one on the system, so whenever someone tries to
> connect to your share, they'll be asked for a username and password and
> be able to user their usual user/pass combo rather than a completely
> different set (which is currently the case).

This is not the correct solution for this problem. If you ask a Windows user
(like you are saying that we should), he will reply that when he shares a
directory on Windows, then no usernames or passwords are required to access
the shared resource *by default*. Moreover, the user is shown a simple
screen where he can then select whether to share read-only or read-write.

Thus, if you want to clone Windows here, you should find a way to share a
directory so that there is no username required to access it *at all*. And
setting security=share achieves exactly this. It might not be the only
solution, but it works.

I think this is Ralf's point, and I totally agree with it. If you don't mind
his tone, I don't think he's wrong.
--
Giovanni Bajo

Is it possible to do USER=SHARE for only *some* folders? If so, it
doesn't seem too difficult to set up a "Shared" folder in each user's
home directory. Would that be a possibility?

On Thu, 2008-01-31 at 22:11 +0000, maybeway36 wrote:
> Users also need a way to turn off passwords (and make a glaring
> security hole themselves), even if it's not the default.
> But yes, the user/passwd database should DEFINITELY be synced.
>
> On Jan 31, 2008 4:21 AM, Soren Hansen <email address hidden> wrote:
> > On Tue, Jan 29, 2008 at 01:13:08PM -0000, Ralf Nieuwenhuijsen wrote:
> > > You said: "Security will not be set to "share". It's an inherently
> > > insecure way to be sharing files."
> >
> > I did.
> >
> > > Soren, we can repeat this _over_ and _over_ again. There is nothing
> > > about security=share that is not exactly as the user would_ expect_ it
> > > to be when installing samba.
> >
> > Look... If you ask anyone who just converted from Windows to Ubuntu if
> > he/she thinks that his/her samba server should be set to security=share,
> > you'll get nothing more than a blank stare. They don't know what it
> > means, they don't care, and they *shouldn't* care!
> >
> > Could you please try focusing on the problem rather than trying push the
> > wrong solution to said problem?
> >
> > We want to make the process of sharing files on your network a) cause
> > the least amount of surprises, but b) without being a gaping security
> > hole.
> >
> > There are several correct solutions (none of which involve
> > security=share). One of them could be to automagically sync Samba's
> > passwd database with the one on the system, so whenever someone tries to
> > connect to your share, they'll be asked for a username and password and
> > be able to user their usual user/pass combo rather than a completely
> > different set (which is currently the case). nautilus-share provides a
> > simple way of sharing folders to the network. Those two things put
> > together, and we win. IIRC, nautilus-share even allows you to allow
> > guest access, so you can make it as insecure as you (apparantly) want.
> >
> > > Use case:
> > > The user wants to share files on his home-network with his family.
> > > The user enables file-sharing, samba gets installed.
> > > File-sharing does not work, because Soren things its unsafe to share files with your family.
> >
> > If you're attempting to achieve a spot in my ignore filter, you're well
> > on your way.
> >
> > Now, if you could please calm down and find a sensible tone for this
> > discussion, that would be lovely.
> >
> > --
> > Soren Hansen
> > Ubuntu Server Team
> > http://www.ubuntu.com/
> >
> > --
> >
> > the security parameter must be set to share, not user, in smb.conf - Smb/Gnome sharing broken
> > https://bugs.launchpad.net/bugs/32067
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>

On Thu, Jan 31, 2008 at 10:18:10PM -0000, Giovanni Bajo wrote:
> This is not the correct solution for this problem. If you ask a
> Windows user (like you are saying that we should),

That's not what I said at all. Quit putting words in my mouth.

I said that if you asked a new Ubuntu user: "So, dude, do you think we
should put security=share in your smb.conf?", he'll have no clue what
you're talking about. Hence, it's completely mistaken to say that "new
users expect that their smb.conf says security=share". No, they don't.
They expect to be able to share their files.

> he will reply that when he shares a directory on Windows, then no
> usernames or passwords are required to access the shared resource *by
> default*.

I find Windows' security model quite uninteresting.

> Moreover, the user is shown a simple screen where he can then select
> whether to share read-only or read-write.

Yes. How is that different from nautilus-share?

http://gentoo.ovibes.net/nautilus-share/mediawiki-1.4.4/index.php/NSScreenShots

> Thus, if you want to clone Windows here, you should find a way to
> share a directory so that there is no username required to access it
> *at all*.

I am *not* trying to clone Windows. At all. Why would you say that?

> And setting security=share achieves exactly this. It might not be the
> only solution, but it works.

"If you don't want to forget your password for your home banking system,
you can just write in on a Post-It and stick it on your monitor. It's
not the only solution, but it works." I'm sorry, but I'm not going to
solve a problem in a way that creates 27 other problems. You may have
the privilege of being able to ignore those 27 other problems. I'm not.
We take security *and* usability seriously.

--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/

> I said that if you asked a new Ubuntu user: "So, dude, do you think we
> should put security=share in your smb.conf?", he'll have no clue what
> you're talking about. Hence, it's completely mistaken to say that "new
> users expect that their smb.conf says security=share". No, they don't.
> They expect to be able to share their files.

At what point has anyone suggested asking an Ubuntu user what settings he would like to set in her SMB.conf? The setting of security=share is merely one of a few solutions in making windows file sharing on Ubuntu simpler. If enabled by default, the user would not have to alter smb.conf at all.

I do appreciate that you are trying to combine usability and security, but simply ignoring the fact that many users are using Ubuntu machines in a mixed network with Windows ones is surely not a good idea. If an Ubuntu user, at the moment, shares a folder, a windows user CANNOT access the folder without access to the Ubuntu users ID, or creating his own. Secure or not, this is not usable.

This is getting _really_ ridiculous.

One of the reasons I dropped Ubuntu is this sense of having to protect users from themselves.

It closely resembles handing somebody a car, but not the keys, because he could do harm to himself and others.

Grown up users deserve grown up distributions.

Have a lot of fun...

On Fri, Feb 01, 2008 at 09:39:10AM -0000, Charlie Halford wrote:
> > I said that if you asked a new Ubuntu user: "So, dude, do you think we
> > should put security=share in your smb.conf?", he'll have no clue what
> > you're talking about. Hence, it's completely mistaken to say that "new
> > users expect that their smb.conf says security=share". No, they don't.
> > They expect to be able to share their files.
> At what point has anyone suggested asking an Ubuntu user what settings
> he would like to set in her SMB.conf?

Ralf claimed that users expect their smb.conf to say security=share. I
contested that based on the fact that the vast majority of users don't
care, don't know that they even have an smb.conf, and *shouldn't*.

> The setting of security=share is merely one of a few solutions in
> making windows file sharing on Ubuntu simpler.

My point exactly. There are several solutions, so why keep pushing the
wrong one?

> If enabled by default, the user would not have to alter smb.conf at
> all.

The point wasn't whether the user had to change his smb.conf. The point
was that that the particular type of user in question has no opinion on
what string of characters are in his smb.conf. He cares about sharing
files, not the technical mechanics of it.

> I do appreciate that you are trying to combine usability and security,
> but simply ignoring the fact that many users are using Ubuntu machines
> in a mixed network with Windows ones is surely not a good idea.

I'm having difficulty conveying the extent to which that sort of
statement irritates me... We are not ignoring the fact that Ubuntu
machines are used in mixed environments.

> If an Ubuntu user, at the moment, shares a folder, a windows user
> CANNOT access the folder without access to the Ubuntu users ID, or
> creating his own. Secure or not, this is not usable.

It seems to be a common misconception on this thread, that the only way
to make files available via samba to unauthenticated users is to tell
samba to use security=share. This is simply not so. If you want
nautilus-share to present the guest_ok setting in its ui, please file a
bug against nautilus-share. Quit suggesting that we turn Samba into a
gaping security hole by default.

--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/

My apologies, I did not realise that setting guest_ok would result in the same view of the shared folder by windows user. I thought that perhaps the guest setting in samba would prompt the windows user of a username and password before accepting a blank. If this is not the case, then perhaps it would be a good idea to add this to nautilus-share, with the pam-samba synchronisation that we were mentioning before.

Actually there is nothing about security. It is about to keep Windowx Xp
incompatible to Ubuntu. The same way m$ do ;)

Let's see some facts:
- Ubuntu (Nautilus) _can_ access Ubuntu(samba) with security=user
enabled
- WinXp _can't_ access Ubuntu(samba) with security=user enabled
- WinXp _has_ security=user by default too, but it _can_ sync usernames.
- ubuntu ( samba ) _can't_ sync usernames, but it keep Guest account
open so Ubuntu ( Nautilus ) can access it.
- WinXp theoretically can access Ubuntu(samba) with security=user
enabled, but it need to know about opened Guest account.
- security=user + opened Guest account = almost the same us
security=share, with one exception WinXp do not know any thing about
this.
- opened Guest account _is_ security problem by default in ubuntu!!!!

So about what kind of security we talking???!!!
Is default security=user real secure???

For example we can use
"security=user (smb.conf default ) " + "opened Guest account (smb.conf
default ) " + "map to guest = Bad User (Nautilus default)"
what is the same what Ubuntu ( Nautilus ) do.

Some more interesting info:
http://support.microsoft.com/kb/300489/
"In Windows XP Home Edition, all network connections are mapped through the Guest account. If the Guest account is not enabled or if the Guest account does not have the appropriate share permissions, the connection does not work correctly. If the Guest account has sufficient share permissions, but the Guest account has not been assigned NTFS file system permissions, you can use the Guest account to connect to the local computer. However, in this scenario, you cannot access files or directories."

Soren:also my apologies, I too always thought user = śhare is the only way. I googled a bit and found that it is indeed possible to have passwordless sharing with:
security = user
guest account = ok
#now this is the important bit that you too omitted, see here: http://lists.debian.org/debian-user/2000/12/msg03643.html
map to guest = Bad User # or Bad Passwords will do as well, Bad User seems better to me, see man smb.conf for details - otherwise it still asks for password.

Do you want me to open a bug against shares-admin aka nautilus-share then? Because I think we could just change the description of this bug ot not lose the history and the number of people interested in it, could not we? And frankly, I am not sure how this solution differs from security = share, so would it be considered at all?

Anyway, if it were to be considered, there is also a problem if one wants to have his shares writable. One solution is to put guest account = "owner of the folder" the other is to change permissions of the share folder (either 777 or owners nobody:nogroup will do), but that brings the problem that if a user (not samba user) creates a folder inside this shared folder, it has got ownership and permissions of that user, so it is impossible to write there through samba unless the permissions are manually changed.

On Feb 1, 2008 8:41 AM, Soren Hansen <email address hidden> wrote:

> On Thu, Jan 31, 2008 at 10:18:10PM -0000, Giovanni Bajo wrote:
> > This is not the correct solution for this problem. If you ask a
> > Windows user (like you are saying that we should),
>
> That's not what I said at all. Quit putting words in my mouth.
>
> I said that if you asked a new Ubuntu user: "So, dude, do you think we
> should put security=share in your smb.conf?", he'll have no clue what
> you're talking about. Hence, it's completely mistaken to say that "new
> users expect that their smb.conf says security=share". No, they don't.
> They expect to be able to share their files.
>

Nobody claimed that users have a specifical technical preference about a
single setting in smb.conf. Ralf (at least in my reading) simply claimed
that there is nothing in the *effects* you obtain by setting security=share
that does not match users' expectations. I will be pleased if you could tell
us what are the unexpected effects of such a configuration, because surely I
don't know samba well enough to understand.

> he will reply that when he shares a directory on Windows, then no
> > usernames or passwords are required to access the shared resource *by
> > default*.
>
> I find Windows' security model quite uninteresting.

I'm not discussing a security model. I'm presenting an usability story that
I feel is particularly important. I think Windows succeeds in giving the
correct usability to users in this regard (and I am not claiming that it is
doing in a way that is sensible from a security point of view -- and I
really don't care right now about this).

> Moreover, the user is shown a simple screen where he can then select
> > whether to share read-only or read-write.
>
> Yes. How is that different from nautilus-share?
>
> http://gentoo.ovibes.net/nautilus-
> share/mediawiki-1.4.4/index.php/NSScreenShots

Yes, that is exactly the same.
<http://gentoo.ovibes.net/nautilus-share/mediawiki-1.4.4/index.php/NSScreenShots>

> And setting security=share achieves exactly this. It might not be the
> > only solution, but it works.
>
> "If you don't want to forget your password for your home banking system,
> you can just write in on a Post-It and stick it on your monitor. It's
> not the only solution, but it works." I'm sorry, but I'm not going to
> solve a problem in a way that creates 27 other problems. You may have
> the privilege of being able to ignore those 27 other problems. I'm not.
> We take security *and* usability seriously.

I'm happy about this, and I am happy if you say "look, there is this other
solution which achieves the same usability but it is much more secure". I am
failing to see any alternative proposal at this point (and I'm failing to
see why security=share is unsecure as I said before, but that is due my
ignorance).
--
Giovanni Bajo

On 2/1/08, Giovanni Bajo <email address hidden> wrote:
> I'm happy about this, and I am happy if you say "look, there is this other
> solution which achieves the same usability but it is much more secure". I am
> failing to see any alternative proposal at this point (and I'm failing to
> see why security=share is unsecure as I said before, but that is due my
> ignorance).

As far as I can tell, it's not insecure, it's just a voluntary choice
by the user to not require any credentials from people accessing the
share, which what many users expect (this is also why this discussion
has heated up). Security is a completely moot topic here if the
problem is that shares can be accessed by Ubuntu machines, but not
Windows XP ones.

The recommended way to deal with complex discussions like this in the Ubuntu world is to write up a "blueprint" (aks "spec") for the issue. It is much easier to get the necessary folks from different teams together and easier to collaborate on the wiki than in a bug tracker.

For example, at UDS in Boston in October 2007, there was a discussion on this issue. The launchpad blueprint is at:
 https://blueprints.edge.launchpad.net/ubuntu/+spec/easy-file-sharing

The wiki page for design and feedback is at
 https://wiki.ubuntu.com/EasyFileSharing

This is a common and difficult issue, so there may be others. But I'd suggest that folks move this discussion to a blueprint so we can be more effective.

Getting a blueprint for this is a very good idea.

@soren

I am sorry for my tone of voice.
I was getting upset, not by the bug itself, but how it is dealt with.

For years now, there is broken GUI functionality in the desktop. No user understands why it is broken.
If you would ask the user 'what do you expect?' .. they would say: 'i chose to share folder X, but it does not work'
What did they _expect_? They expected it to work _without_ requiring a password.

During all those years people have complained about this. We are told it is insecure. None of _us_ understand _why_.

You, being the expert, obviously does understand it. But could please communicate why the behavior a desktop-user expects is bad?

We can all imagine this behavior would be the wrong default for a server. But I didn't install server. I installed a desktop. I didn't share all my files, the GUI already had me pick which folder(s) to share. I choose things like my music and my photo's.

Again, my apologies for my tone. Could you please give us an official statement what is wrong with us, wanting to share files without a password? Why shouldn't we do this?

Thank you in advance, in name of all frustated desktop-users that as this point. We would really like an explenation.

It's much worse than user vs. share.

Something must do name resolution. Probably the simplest way is hosts with
server names (not FQDN). Without it, the Gnome browser refuse to display
anything and gives no useful error message other than I can't do that.

The fastest route to a behind a gateway Windows Network is share. That only
requires running the Windows network wizard, setting up fixed IP addresses,
setting up a hosts file on all the computers on the network and replacing
smb.conf with a very simple configuration (but not one obvious to any but a
fairly sophisticated user).

Of course it is insecure. Running Windows file sharing without a gateway
router is insane in the first place. Of course, one of the Windows boxes may
be hooked. Is there any reason to protect Windows users beyond a warning?

Jim

On 2/3/08, Ralf Nieuwenhuijsen <email address hidden> wrote:
>
> @soren
>
> I am sorry for my tone of voice.
> I was getting upset, not by the bug itself, but how it is dealt with.
>
> For years now, there is broken GUI functionality in the desktop. No user
> understands why it is broken.
> If you would ask the user 'what do you expect?' .. they would say: 'i
> chose to share folder X, but it does not work'
> What did they _expect_? They expected it to work _without_ requiring a
> password.
>
> During all those years people have complained about this. We are told it
> is insecure. None of _us_ understand _why_.
>
> You, being the expert, obviously does understand it. But could please
> communicate why the behavior a desktop-user expects is bad?
>
> We can all imagine this behavior would be the wrong default for a
> server. But I didn't install server. I installed a desktop. I didn't
> share all my files, the GUI already had me pick which folder(s) to
> share. I choose things like my music and my photo's.
>
> Again, my apologies for my tone. Could you please give us an official
> statement what is wrong with us, wanting to share files without a
> password? Why shouldn't we do this?
>
> Thank you in advance, in name of all frustated desktop-users that as
> this point. We would really like an explenation.
>
> --
> the security parameter must be set to share, not user, in smb.conf -
> Smb/Gnome sharing broken
> https://bugs.launchpad.net/bugs/32067
> You received this bug notification because you are a member of Ubuntu
> Server Team, which is a bug contact for samba in ubuntu.
>

On Sun, Feb 03, 2008 at 11:59:19PM -0000, Ralf Nieuwenhuijsen wrote:
> For years now, there is broken GUI functionality in the desktop. No
> user understands why it is broken.

To those users: Rather than assuming we're idiots (we're not), or that
we don't care (we do), I suggest you ask.

> If you would ask the user 'what do you expect?' .. they would say: 'i
> chose to share folder X, but it does not work'

Right. Most care about functionality. Not technology.

> What did they _expect_? They expected it to work _without_ requiring
> a password.

That might be what *you* expect. I doubt you've asked all of our
millions of users whether they think you should be asked for a password
when connecting to a share. I certainly haven't. Hence, I try to avoid
making such specific assumptions about their wishes. I recommend a
similar approach.

> During all those years people have complained about this. We are told
> it is insecure. None of _us_ understand _why_.
>
> You, being the expert, obviously does understand it. But could please
> communicate why the behavior a desktop-user expects is bad?

It's not like it's a secret or anything. It's been discussed in many
places many times before. The short version:

If you're using security=user and connect to Samba, you'll be asked for
a username and password. If succesfully authenticated, the Samba process
on the server will switch to running as your user on the system. This
ensures that the file system restrictions the Unix model imposes is
properly respected. This is a very good thing.

If you're using security=share, the client doesn't (or at least: is not
required to) send a username when it connects, so to switch to a
different user (to avoid running as root), Samba has to guess which user
you are. Unless you've taken explicity measures to avoid it (and based
on the type of users we're talking about, I'm guessing most will not
have done so), the password sent to the server will checked against each
and every user in turn until one of the is succesfully authenticated.
That's really the crux of the problem. This means that a malicious user
doesn't even have to bother guessing user names if we wants to crack
your Samba server. He can just try a short list of common passwords, and
Samba will check each password against each and every user on the system
until it succesfully authenticates. Again, considering the type of users
we have to take into consideration here, I'm not going to make very
strong assumptions of the quality of their passwords...

Even if you disregard malicious users, you also have a problem if
multiple people on the system have the same password (after all, they
are likely to have the same family name, street name, etc.). You might
all be acting in good faith, but because of Samba's behaviour in this
area, you could end up accessing someone else's files when you were
trying to access your own.

In summary, the only situation where there is *no* risk involved in
this, is if you're on a separate network (not connected to the internet
at all), and there's only a single user on the network to worry about.

I have no statistics to back this up, but I'm quite confident this is
not a ver...

How's this:
"share" account
"shared" group
"Shared" folder in each homedir

"share" account is not allowed to log into a normal session.

Daemon monitors the "Shared" folders, and changes the group of the file
to "shared" if something gets dropped in the Shared folder.

User is prompted to give the "Shared" account a password as soon as:
1) Sharing is enabled, if this must be done manually
2) The first file is dropped into the "Shared" folder

If the user opts not to give the "Shared" account a password, a warning
is given, and it then allows the user to do this.

..good?

On Mon, 2008-02-04 at 08:10 +0000, Soren Hansen wrote:
> On Sun, Feb 03, 2008 at 11:59:19PM -0000, Ralf Nieuwenhuijsen wrote:
> > For years now, there is broken GUI functionality in the desktop. No
> > user understands why it is broken.
>
> To those users: Rather than assuming we're idiots (we're not), or that
> we don't care (we do), I suggest you ask.
>
> > If you would ask the user 'what do you expect?' .. they would say: 'i
> > chose to share folder X, but it does not work'
>
> Right. Most care about functionality. Not technology.
>
> > What did they _expect_? They expected it to work _without_ requiring
> > a password.
>
> That might be what *you* expect. I doubt you've asked all of our
> millions of users whether they think you should be asked for a password
> when connecting to a share. I certainly haven't. Hence, I try to avoid
> making such specific assumptions about their wishes. I recommend a
> similar approach.
>
> > During all those years people have complained about this. We are told
> > it is insecure. None of _us_ understand _why_.
> >
> > You, being the expert, obviously does understand it. But could please
> > communicate why the behavior a desktop-user expects is bad?
>
> It's not like it's a secret or anything. It's been discussed in many
> places many times before. The short version:
>
> If you're using security=user and connect to Samba, you'll be asked for
> a username and password. If succesfully authenticated, the Samba process
> on the server will switch to running as your user on the system. This
> ensures that the file system restrictions the Unix model imposes is
> properly respected. This is a very good thing.
>
> If you're using security=share, the client doesn't (or at least: is not
> required to) send a username when it connects, so to switch to a
> different user (to avoid running as root), Samba has to guess which user
> you are. Unless you've taken explicity measures to avoid it (and based
> on the type of users we're talking about, I'm guessing most will not
> have done so), the password sent to the server will checked against each
> and every user in turn until one of the is succesfully authenticated.
> That's really the crux of the problem. This means that a malicious user
> doesn't even have to bother guessing user names if we wants to crack
> your Samba server. He can just try a short list of common passwords, and
> Samba will check each password against each and every user on the system
> until it succesfully authenticates. Again, considering the type of users
> we have to take into consideration here, I'm not going t...

I've edited the summary to clarify what is known about this bug,
including a one line solution that seems to be acceptable - I've
tested that it's factually correct using GNOME, Windows XP on qemu,
and samba, all running on the same machine. I suggest that commenters
reread the summary before saying anything new.

this fix works perfectly for me. and fixes sharing files with macs running OSX too, (although that may be a completely different issue). hope we see it for hardy

should there also be a checkbox in every share dialogue that says:
[x] Allow any user on your local network to view this folder.
which controls the "public = yes" line in smb.conf for the specific folder? Of course, it should be checked by default, as it is clear from this thread that users want to share their files when they click share.
This gives the expected effect: simple passwordless guest access when checked, prompt for password when unchecked

if this isnt possible, the solution named in the bug summary should definitely be implemented for hardy

I have two questions:

1. will this bug finally be fixed in Hardy?
2. has the 'correct' solution been a mystery for all these years? (the "Map to guest = Bad User")
3. will you make the fact that it finally works part of the official Hardy Release Notes?

I know this sounds like frustration. (it is) But given the way this has taken place, you can expect us to be cynical about this bug getting fixed even when the fix is known, after all these years... you have to give us (me) some slack here. We've spent cumulatively hours, perhaps even days, whereas a server-expert would have been able to fix this in minutes. (considering we were side-tracked by user=share and the info is in the man-page of smb.conf)

But if this fix really does land in Hardy. I would like to nominate it for the official release notes.
It would be the first Ubuntu release with working Samba for the end-user.

Sounds like a major feature to me. Bigger than vineagre, kvm and pulse-audio-by-default.
Something users will really notice.

And if its not in the release-notes, everybody is going to the terminal, doing sudo gedit /etc/smb.conf and setting it to user=share. (which appearantly is unsafe.). Because at this point, everybody expects the gui to be broken.

2 years. 83 comments. and all we needed was Guest Login = Bad User.

Wow.

> 2 years. 83 comments. and all we needed was Guest Login = Bad User.
>
> Wow.

*nod* I know exactly where you're coming from on that. I'm pretty
exhausted with trying to get some things even acknowledged, much less
done. There's a general communication problem, in my opinion. Perhaps
it's just me. Anywho, I think Ubuntu just grew up too fast -- see bug
#59695, reported on 2006-09-09, for another example.

I really love Ubuntu, and want to see it grow, but I hope this issue is
visible to some people that care and can do something about it. There
has to be a better way to organize the community to get things done more
effectively.

"to get things done more
effectively."

There seems to be a large gap between how the ubuntu develops use ubuntu and rest of us, and what they like to work on, and what we would like them to work on.

 In general if less than 90% of the people is able to do these basic things, the release should be delayed:

  - being able to boot the live-cd and install ubuntu (like dapper, and it seems like hardy will have this too)
  - being able to connect to the internet
  - being able to share files with people on the network (like samba being broken forever)
  - being able to edit a document and save it
  - being able to play a song (like rhythmbox shipping with gutsy gibbon with broken sound on about 50% of the pcs out there)
  - being able to keep the computer running and not have it crash while doing nothing (up until feisty!) (the default screensaver used to use 3d, which crashed with matrox, old intel and old ati cards. say 40% of the people)

The intrinsic problem seems to be fun. Compiz is more fun to work on. KVM is more fun to work on for a server-expert. Working on Poly-audio is more fun than making rhythmbox not scratch on half the soundcards out there. But they end up shipping a very broken system and misleading people to believe 'its just their weird computer'.

I still can't believe they added compiz, tracker, deskbar and put all those work into the bling and other release-note-show-off-features instead of getting the basic tasks working. It's not that anybody here minded trying to triage the bug ourselves, while the experts worked on the fun stuff. We though we did actually solve it (with user=share). But instead of putting in 10 minutes of effort into fixing the problem, they put in half an hour of effort to explain why our solution is wrong. Which blows my mind even more. user=share would still have been a better fix than no fix.. It's what everybody is running now, after googling and copy & pasting instructions from forums. Honestly, it's just plain embarrising.

*nod* that's the same thing with the hard-disk eating bug. Most systems
are fixed by turning APM off on the disk drive. This is a one liner
that can be dropped in three directories and fix the problem for 90% of
the people. Granted, it is not a *FIX* fix, but it makes it work
without problems for more people than it would otherwise. But, things
have just.. ..floundered. There are partial fixes, and they aren't
implemented because they don't work for everyone. So people go, cut and
paste from forums, not knowing what they heck they're cutting and
pasting, and hope the person 1) got it right and 2) wasn't being
malicious.

Can you think of a method of communication (I mean, proposals, bugs
filed on launchpad about launchpad, forums, emailing people, ??) that
would have a decent probability of success in getting this communication
issue fixed or at least partially addressed? There are lots of things
that can be done about it, from a technical standpoint -- even just to
something as simple as having "escalate" and "de-escalate" buttons, and
then a listing of bugs by their escalation value.

> I still can't believe they added compiz, tracker, deskbar and put all
> those work into the bling and other release-note-show-off-features
> instead of getting the basic tasks working. It's not that anybody here
> minded trying to triage the bug ourselves, while the experts worked on
> the fun stuff. We though we did actually solve it (with user=share).
> But instead of putting in 10 minutes of effort into fixing the problem,
> they put in half an hour of effort to explain why our solution is wrong.
> Which blows my mind even more. user=share would still have been a
> better fix than no fix.. It's what everybody is running now, after
> googling and copy & pasting instructions from forums. Honestly, it's
> just plain embarrising.

Well, I can believe they did -- the glitz is nice, and the tools useful
-- but, it seems to me that after a couple of releases (feisty, gutsy)
of new stuff, the focus for hardy should be on getting stuff working
all around. ..and being named "hardy", I think that was the intent.

Anywho, this mostly doesn't belong on this bug, I suppose, though
hopefully it will get some visibility, and perhaps we can do something
about it. If you happen to know of other bugs in which people are
disgruntled or disappointed in the process that's going on, please fire
an email off to me at <email address hidden>. In aggregating that
info, I might be able to get a better idea of what the problems are and
how to deal with them, and the better of an idea that I have, the more
likely it is that I and others will be able to put together something
that causes some change.

-brian

> - being able to boot the live-cd and install ubuntu (like dapper, and it seems like hardy will have this too)

Not clear the CD doesn't boot for most users and not easy to change because it would mean to have access to the hardware of every configuration concerned

> - being able to play a song (like rhythmbox shipping with gutsy gibbon with broken sound on about 50% of the pcs out there)

dunno where you are getting your number but it's most likely a very wrong estimation, sound works correctly on most configurations

> I still can't believe they added compiz, tracker, deskbar and put all those work into the bling

Those are things which have been coded by upstream and not the ubuntu team, packaging them didn't take a lot of ressources avoid from bug fixing, you are speaking to the wrong persons there. And people who have worked on that most likely did it because that's what they want to do and would not have worked on other bugs anyway

You seem to not undersand how opensource is working, ubuntu is mostly doing packaging work and bug fixing, shipping code written by other people is not what prevent fixing all those bugs, the issue is just the small number of people doing the work and the huge workload there.

Now the code is available and you can make a difference and start contributing and fixing issues too

:/
How does "map to guest = bad user" fix anything? Sure I can get into
the share w/out a password prompt, but now it's read only.

2008/2/29, Sebastien Bacher <email address hidden>:
>
> Not clear the CD doesn't boot for most users and not easy to change
> because it would mean to have access to the hardware of every
> configuration concerned

Nobody expects the ubuntu devs to fix all the bugs in a specific kernel
version. Off course, it does make sense to use kernel versions that are
known to work. So, if there are mission critical (unable to install/random
crashes/etc.) type of bugs for a not that small minority it would make sense
to default to a proven kernel early on. For hardy, which in every alpha
release note, still warns about a simerlar problem, it is already too late
to switch back. And you don't have al the hardware of every configuration
available. So, this might end up being a release bug. Yikes.

> dunno where you are getting your number but it's most likely a very
> wrong estimation, sound works correctly on most configurations

It was a known bug in Rhythmbox. The workaround was easy: turn volume of
rhythmbox to the maximum, or, switch to the crossfade backend. The actual
cause has been fixed after the release, but the release did not even enable
the workaround by default. So people had to go to launchpad or ask their
friends to find out all they had to do was enable the crossfade or keep the
volume at the max.

Again, nobody is expecting anybody to fix the issue. Resources are limited,
etc. But is the amount of effort to default to the crossfade backend, really
quantifiable?

Those are things which have been coded by upstream and not the ubuntu
> team, packaging them didn't take a lot of ressources avoid from bug
> fixing, you are speaking to the wrong persons there. And people who have
> worked on that most likely did it because that's what they want to do
> and would not have worked on other bugs anyway

You might be very right about that. But that was exactly my point. There is
little interest, even in fixing default configurations. We're not even
talking code here. Just a different /etc file or gconf settings.

You seem to not undersand how opensource is working, ubuntu is mostly

> doing packaging work and bug fixing, shipping code written by other
> people is not what prevent fixing all those bugs, the issue is just the
> small number of people doing the work and the huge workload there.

I _do_ understand. I'm not demanding this works. I just expect the
maintainers to either remove it from the default install or add a
'perhaps-not-the-most-perfect' fix that is a single line to a configuration
file.

Because from where I am standing, the biggest problem of samba being
configured wrong is the confusion. People see an interface to enable it, but
it doesn't work. Until it actually works, why is this interface even
offered? People are going to check their network cables. Spent hours on
forums finding the solution.

How would you quantify the effort to just remove the .desktop file? Shipping
a completely broken piece of software is much worse than not shipping it at
all. It decreases the quality of the total desktop. Not to mention the
people I support would call me when they want file-sharing, rather than
waste their own time unsuccesfully.

Now th...

> Again, nobody is expecting anybody to fix the issue. Resources are limited, etc. But is the amount of effort to default to the crossfade backend, really quantifiable?

Did you read bug #138728? That's an interesting bug about playing being choppy when using crossfading and it got quite some duplicates. Now look for other bugs happening when crossfading is used and you will notice quite some issue there. Right, crossfading is not perfect and it doesn't seem to be an easy workaround as you would suggest and that's why we did did this change.

> You might be very right about that. But that was exactly my point. There is little interest, even in fixing default configurations. We're not even talking code here. Just a different /etc file or gconf settings.

The statement is just wrong. We do change when they make sense usually. The example you took is a good one, it has real reason why we did do that change, you might not know why but that might be because you have not looked enough at the situation before juging?

Anyway this discussion is out topic for the bug and no really constructive, let's stop it there

On 2/29/08, maybeway36 <email address hidden> wrote:
> :/
> How does "map to guest = bad user" fix anything? Sure I can get into
> the share w/out a password prompt, but now it's read only.

I don't see any such problem on my end. Make sure that in smb.conf
you have "writable = yes" or "read only = no" (you can set this with
the Shared Folders utility in GNOME), and that other users have
Unix-style permissions to write to the shared folder (you can set this
in nautilus by selecting "Properties" in the right click menu, if you
don't use chmod)

On 3/2/08, Sebastien Bacher <email address hidden> wrote:
> Anyway this discussion is out topic for the bug and no really constructive, let's stop it there

This question remains: is putting "map to guest = Bad User" into the
[global] section of the default smb.conf an acceptable solution to
this bug? If there is a problem, it should be discussed in this bug,
and if there is no problem, it's a quick fix, and the bug should be
fixed by now.

This bug was fixed in the package samba - 3.0.28a-1ubuntu2

---------------
samba (3.0.28a-1ubuntu2) hardy; urgency=low

  * debian/smb.conf
    - Add map to guest = Bad user, maps bad username to guest access.
      (LP: #32067)

 -- Chuck Short <email address hidden> Thu, 27 Mar 2008 14:24:13 -0400

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Jim

Jim Tarvid
Internet Engineer at LSNet
Johnson City, Tennessee Area

Confirm that you know Jim Tarvid
https://www.linkedin.com/e/yc0aq6-goaoxnug-3x/isd/3040027835/mmLW81Jp/

--
(c) 2011, LinkedIn Corporation