"easy" file sharing not notifying about logout/login

Indeed. After samba installation, we should have a notice to ask for a logout/login..

More informations on this bug.
We must advise user that he have to logout/login. This is important because :
1/ logout/login is necessary because user have been put in sambashare group and to take care of it.
2/ logout/login is necessary to let libpam-smbpass populate the samba password by syncing with user password.

Another way to solve that is, may be, to hack samba and libpam-smbpass packages for add notification in their postinst file (like firefox3 do, saying to user that firefox must be restarted)

On Fri, Apr 11, 2008 at 06:08:57AM -0000, Patrice Vetsel wrote:
> Another way to solve that is, may be, to hack samba and libpam-smbpass
> packages for add notification in their postinst file (like firefox3 do,
> saying to user that firefox must be restarted)

I think that would be incorrect in this case; it's only in the case of
wanting to use nautilus-share for managing shares that you should be told
that this is needed.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

So nautilus should be hacked so that when the install is done, it tells you to login again, just like it told you before that you needed to install packages. Isn't there any workaround to avoid the need of relogging in?

There needs to be a dialouge.

I´m install in my desktop and my laptop ubuntu 8.04 stable, in the two machines I have this "problem".

I think that is necessary to advise the user about the logout/login to work.

> Isn't there any workaround to avoid the need of relogging in?

we could use "su $USERNAME -c" to run the command. This would require the user to enter their password, but would work without the user needing to be in admin.

I think the best solution may be to give a notify message, just like when you reinstall Firefox and it tells you you need to restart Firefox for the changes to take effect, or the circular arrow you get notifying you of a need to reboot like when you install a new kernel.

Is there any way that this can be resolved without requiring the user to log in and log out? I, for instance, use Ubuntu because it's stable and polished and I don't have to restart and log in and log out all the time. This would be the ideal behaviour.

As it is right now the error it spits out isn't really all that useful unless you already understand what's going on. My use case is this: I right-clicked on my home folder, selected "Sharing Options". I checked the box to share the folder, and Ubuntu installed the correct software for me. This is excellent behaviour. However, when I tried to click "Create Share" the dialogue box presented me with an error that I found less than informative. I am not a power user, I do not know what these things mean. It would be wonderful if, even after the system tells me to log out and in again, if that error was at least a little more informative.

Also, the same thing with the error I get when I try to name a share with the same name as my username, which is a very common thing when one shares ones home folder. That error message could be more informative, but ideally Ubuntu should detect that you are attempting to share your home folder and name it [username]-home instead.

But ideally I would prefer not to have to log out and log in again. I have quite a few programs I want to run and not be interrupted: Skype, Transmission, Pidgin, etc.

@Daniel: the fact that the user needs to logout/login is a basic property of how the permission system works on linux, and in any *nix system. i.e. the system checks user's groups at login.
Anyhow, on "other" systems you need a reboot, login/logout is cheap.

why did we not have to login/logout on gutsy? or why was this bug not apparant?

It can be correct for linux security system. But how I can explain to the
user, that he should restart his computer for share a folder?! Former
windows users will laugh over me.

That's not restarting to share a folder, that's relogging the first time you enable network shares. Windows users have known worse! ;-)

Could some developer confirm that using a 'su -c $USERNAME' trick could work? This is the best solution.

Kai, you only have to login/logout ONCE when you share a folder the first time ever. After that, folder sharing does not require logging out or restarting.

> Could some developer confirm that using a 'su -c $USERNAME' trick could work? This is the best solution.

Why do you need a developer? Couldn't you just test it yourself, or read the log I posted at: http://brainstorm.ubuntu.com/idea/7883/

@TheHobbit

If that is the case -- and I don't think it is necessarily the case -- then that's something that needs to be changed or worked around. It feels like working with Windows 95 or something.

I think a better solution to this is simply make samba part of the ubuntu-desktop meta package, this IS a desktop. By default with no folders shared you get no inherent security risks.

Artem, it is all excuses!

1. In any case user should know, that is necessary to relogin, but how user
can know that? It is not written anywhere about relogin.
2. It is really ridiculous, that I must relogin for share my folder. Yes,
only first time, but where is a Linux Power? I shall not speak any more,
that it can be necessary in the middle of the working day, when I have many
programs started. And necessity to relogin causes discomfort and
disappointment. "Oh this devil's linux..." (c)

2008/5/3 Артём Попов <email address hidden>:

> Kai, you only have to login/logout ONCE when you share a folder the
> first time ever. After that, folder sharing does not require logging out
> or restarting.
>
> --
> "easy" file sharing not notifying about logout/login
> https://bugs.launchpad.net/bugs/212098
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I tried running su $USERNAME -c groups and it showed me being in the sambashare group, but when I tried to share a folder I still got the message "'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error Permission denied
You do not have permission to create a usershare. Ask your administrator to grant you permissions to create a share."

The error message doesn't give any hint about needed to log out/ log in, so the user experience is quite bad.

You would have to close nautilus first, run 'su $USERNAME -c nautilus', and then choose the folder to share. Not a very nice workaround while the program does not perform this by itself...

I'm have this problem, except logging out (or even rebooting) does not solve it. The user is already in the sambashare group, by the way, and this is a clean Hardy install. Any ideas?

You should be able to use the following command instead of re-login.

$ newgrp sambashare

I gotta tell you that everyone around here is wishing that Ubuntu developers would put things back exactly as they were in Gutsy. That was the easiest thing since sliced bread, and it's stable as a rock. We've been using it for months with no problems at all. We installed 8.10 LTS, and this problem has been a HUGE hangup. We got so frustrated with it that we tossed 8.10 LTS out and went back to 7.10.

If any devs read this, PLEASE change all SAMBA file sharing processes back to the way they were (exactly) in 7.10.

thanks!

I like the changes that have been made to samba; it really is point-and-click to share things now. The only problem I have experienced with it is this bug, which can be solved easily by a user logging out and in again. While it would be great to see a fix, it's hardly a reason to revert back to Gutsy imo.

couldnt we just change the text in the dialog to be something more useful.
ie change:
'net usershare' returned error 255: net usershare add: failed to add share public. Error was Operation not permitted
to:
'net usershare' returned error 255: net usershare add: failed to add share public. Error was Operation not permitted. You may need to log out.

Yes, exactly the same thing happened to me. Logout, login solved the issue.

It would be nice to have this fixed.

Thanks

I understand that modifying groups requires a logout (although I've been hacking UNIX for 20+ years and I still don't really understand why that's true). But it's monumentally sucky to have to log out, even if there's some dialog that tells you you need to do it.

I don't see why nautilus-share cannot be included as part of the base distribution so that this is not necessary. But, if it indeed cannot be, then maybe we should change the base package to add the sambashare group, even though it's not used by any packages until nautilus-share is installed. User accounts can be added to that group as they would be other groups, when the user account is created. This would fix the need to log out/in due to group updates.

Bug 238224 is relevant here. I'm just checking up with Steve Langasek about it, but it seems like a basically reasonable thing for the installer to do for the first user, which would alleviate this for many people.

Of course, that isn't *sufficient* because libpam-smbpass needs to get a chance to see the user's password in order to do non-anonymous sharing ... although you can deal with that by running something that requires administrative privileges so that it asks for your password. Still a bit ugly, though.

I have a fresh hardy install. Actually I installed from a 7.10 CD and immediately upgraded to 8.04
I followed the instructions to edit smb.conf and change "workgroup = localname" to the local workgroup name. I then logged out and back in. The network file browser shows the "windows network" icon. properties shows the new name as "network" when it should be "localname"

Is this part of the problem or a new bug?

We should do *something* about this for 8.04.2, whether it be installing libpam-smbpass by default (probably not a great idea) or including UI that asks for the user's password to enable non-anonymous sharing if necessary (seems cleaner). This needs to shake out in Intrepid first, though.

(Per bug 238224, the first user is now automatically added to the sambashare group in Intrepid.)

> or including UI that asks for the user's password to enable non-anonymous sharing if necessary (seems cleaner).

Presumably by using gksudo? Wouldn't it be just as easy to use newgrp in place of gksudo, and save users the need to re-enter their password?

this bug was not present in 7.10 and is therefore a regression. i do not think that you should have to relogin/restart the computer in order to start setting up shares, that is way too inconvenient, and you didnt have to do that in gutsy. instead, how about automatically restarting samba after installing the sharing services, that way you dont need to restart?

or you could make it so that samba is never started in the first place until you are finished installing the services, or something like that?

whatever. it doesnt matter how its fixed, as long as its fixed in the best way possible. :) i do not want to have to logout and then log back in to start sharing stuff after installing, many people will find that inconvenient and will be annoyed, even though it only happens once (it shouldnt happen at all).

Jessie - The problem isn't that the Samba daemon needs restarting. The problem is that nautilus-share (which was introduced in to Hardy) uses a feature of Samba called 'usershare', which allows the administrator to control who can add shares. The administrator does this by adding users to the 'sambashare' group. Members of this group can then add and remove shares.

The maintainer scripts for Samba automatically add all users who are members of group 'admin' to group 'sambashare' when Samba is installed. However, the user won't belong to this group until they log out and back in again (and I don't think that there is any way around that).

This wasn't a problem in Gutsy because the usershare feature wasn't used, and users were not added to a new group when Samba was installed. In Gutsy, only administrators could add/remove shares.

Hope that clarifies it a bit.

Chris Coulson wrote:
> The maintainer scripts for Samba automatically add all users who are
> members of group 'admin' to group 'sambashare' when Samba is installed.
> However, the user won't belong to this group until they log out and back
> in again (and I don't think that there is any way around that).
>
Is it possible to query the group database directly, so the feature is
activated as soon as the user is added?

Mark

Nautilus runs as "me" and needs to write the share data into the following place:

drwxrwx--T 2 root sambashare 4096 2008-07-28 21:05 /var/lib/samba/usershares

But this place is only writable to "sambashare" members, which I do not belong until I relogin.

It does not matter if you have some application running as 'me' to know that I am authorized to write there, it would require something that has the priviledge to write into this place, which is either a suid command or a daemon.

Suid commands are evil and should be avoided, so a little process would be required that has the persmissions to write there and handle the authorization.

The question about the process is, if it is an advisable way, as you don't want to have for every little thing a running process lying around and wasting your precious resources.

The very best way would be, if linux could handle group memberships dynamically, but as Chris stated this is a very hard way to take, as it would require to change things the way they worked for decades - but it would be a very nice feature, that would be quite handy not only for samba but possibly other things!

Another way would be extended attributes, which would allow the adm AND the sambashare members to write to the directory, but you might want to get some further input before you decide that you want to go fore extended attributes, as they are for example not handled by some applications like tar and probably nautilus and may quickly become as messy as the file permissions fiasko of this other OS mentioned in bug #1.

From my viewpoint you have 3 basic choices:

1: Inform the user, like you do that Firefox needs restarting and reboot due to kernel updates, that he has to logout as he got a new group membership, this way, the users knows that to do and has not to handly cryptic error messages until he finds out by accident to do a re-login.
2: Do some framework, daemon, suid, extended attributes, which may give you some work, maybe more than expected and lead into unwanted troubles.
3: Implement dynamic group memberships - as mentioned, this is the hardest possible way, as it requires probably fundamental changes (I dunno).

* Imagine: You would have a Client Desktop and a Linux Fileserver, and you need access to something, but you don't have the access rights - so you call your sysadmin for the permissions to access that file, that mailfolder or whatever, of course the sysadmin would check if you are entitled to get access, but for the examples sake would give you the permissions by adding you to the group 'X' to access to precious files/mail/whatever. Now, what today is well known is that the user has to close all running applications and re-login to make the groupmembership happening. If linux would overcome this, it would be quite something!

Mark,

I'm not sure it is that simple with the current Samba implementation, because it isn't a case of Samba querying whether the user belongs to the correct group or not when a share is created. The Nautilus-share extension (running with normal user privileges) needs write access to /var/lib/samba/usershares in order to create a share. Only root and members of 'sambashare' can write to this directory, and this is the Samba implementation of controlling who can add shares. This problem is purely down to the user not immediately gaining the privileges to write to this folder, when they are added to the group. Unfortunately, I think this can only be solved by logging out and back in again.

Maybe this situation could be improved with Policykit in the future.

Phoenix - Thank you for your response.

When you describe having a daemon that is privileged enough to create shares on behalf of the user - this is basically how GNOME System Tools / System Tools Backends works already for handling system configuration (if you weren't already aware).

@Mark: I think the problem most of us have is not that you have to reboot, but that the user is not properly notified to reboot. So the first time one goes to share folders they come to the conclusion that they are ready and then run in to an error that does not give helpful information. If the user was simply notified that a reboot is required instead of given unhelpful error messages that would be great.

@DavidBaucum: I can't believe that nice error message saying that user needs to reboot can be considered as a fix. It's of course necessary with current implementation, but's just a workaround in the best case!

It should work without re-login, as at windows and mac. If that OS can do that, also ubuntu should.

I also found the idea, that dynamic updating user permissions is a nice feature, but isn't it just to change a few functions in the standard library?

ok, that was clarifying.

anyway, i think that a message saying the user must relogin is still unacceptable. the problem is not that the error message doesnt contain helpful information. the problem is that ERRORS ARE BAD. we should not get an error in the first place. it is inconvenient and unnecessary (and confusing) to have to log out and log back in

it seems that there are a LOT of suggestions as to how this can get fixed, why not implement them? dynamic updating user permissions, restarting nautilus and "su -c $USERNAME", and "newgrp sambashare" are three ways. i will test and see if "newgrp sambashare" will work and post the results here very soon.

@saepia: I absolutely agree that Ubuntu should not force you to reboot. That is ideal and hopefully attainable. However, the current situation is beyond unacceptable. The way it currently works is sloppy. A user selects to enable sharing and is given an error that is inaccurate and frustrating for the end user. A simple message telling the user they need to reboot, like one gets on a kernel update, would be world better than the current way things are done. This short-term fix should also be much easier to implement until the optimal long-term fix is in place.

@jessie Lawrence: Giving the wrong error for a problem is what is unacceptable. Accurately informing the user they need to reboot is exactly what needs to done until the back-end work can be hammered out so no reboot is necessary.

> It should work without re-login, as at windows and mac. If that OS can do that, also ubuntu should.

It is more a question of security. On windows and mac, all users are authorized to create shares, unless explicitely denied by their admin in some group policy (on Windows). We can do that too, we just have to ship the /var/lib/samba/usershares directiry with a "users" group owner, that way all users are by default authorized to create shares. Then it would be up to the admin to give another group to that directory (i.e. sambashare) if he wants to tighten security more...

But that's not the usual Linux way, as we don't want to give up security for useability. The best fix to get security and useability is to find some way to automagically refresh group membership, that way we fix this bug but also all others where you ahve to restart after being added to a group.

On my Ubuntu 8.04 (with russian locale) after I requested sharing the folder and accepted samba installation, I still had the error 255 no permissions for net usershare.

The reason was simple. When editing sambashare usergroup I noticed, that my account is added to group, BUT UNCHECKED. I needed to check it, logout, then login again and all worked ok.

On some reason user account is not activated in sambashare usergroup.

I have forgotten to add, that my Ubuntu is fully patched on today (19-09-2008).

Hi, I thought I'd chime in. I'm a java programmer with 14 year of Win32 experience.
I'm a ubuntu virgin though. When I tried to share a folder I did it like I would on OSX/win32: First, I tried to share a drive (fail), so I then tried a folder, found the 'sharing option'.

Went in there, added the non-installed bits, and when I tried to create my share, bang, error message '255 etc'. Barely noticeable as well since the message is displayed at the bottom of the window.

So what do you think a linux virgin did? I remembered about this 'gksudo' thing,... you imagine the rest.

This IS a bug - the only way around it would be 1) make sure it's shareable immediately or 2) inform the user clearly that a re-login is needed.

My two cents of course. Oh and by the way, a 'normal' user would be unable to even find this launchpad page, and would give up on sharing folders in ubuntu very quickly.

A notification to restart should be added before Intrepid release. This can be done in the same style as the firefox notification. Even if this is considered a workaround rather than a complete fix, this would drop the importance to medium, and it should be fairly easy to implement.

Another note - I was unable to create the share anyway, after logout OR restart (twice).
The only way around it was to do what the error said, add that line in smb.conf. It works now, but I'm not sure if adding the line is a security risk or not (to be honest I don't care anymore after 3 hours of trying to make this work).

As per the Ubuntu Desktop team meeting discussion: When trying to enable sharing when samba is installed, the user is in sambashare now, but the process isn't yet, the "Install samba?" dialog should be replaced with a "You need to restart your session in order to enable sharing. [Restart now] [Cancel]" message box. This should also appear right after installing samba.

Is anyone interested in working on a patch for this soon?

Martin Pitt wrote:
> As per the Ubuntu Desktop team meeting discussion: When trying to enable
> sharing when samba is installed, the user is in sambashare now, but the
> process isn't yet, the "Install samba?" dialog should be replaced with a
> "You need to restart your session in order to enable sharing. [Restart
> now] [Cancel]" message box. This should also appear right after
> installing samba.
>
> Is anyone interested in working on a patch for this soon?
>
As long as we recognise that a logout is suboptimal and can only be a
temporary solution!

Martin,

As a temporary solution, would it not be easier to use the infrastructure provided by update-notifier for notifying the user that they need to restart their session (as opposed to creating a whole new dialog). This is how the Firefox package currently notifies the user that they need to restart Firefox after an upgrade. Ok, it's not as good because the user isn't offered any buttons to restart their session (they only get a balloon in the notification area) - but it is quicker/easier and as Mark as pointed out, the solution is suboptimal (and temporary) anyway.

@Martin Pitt:
In stead of a reboot, how about advise of a need to log out/log in. A complete restart seems like overkill when a logout/login is sufficient.

DavidBaucum: I don't think Martin wasn't suggesting a complete restart. He was suggesting a session restart, ie logout/login.

FYI, I am working on it.
On #ubuntu-desktop, seb128, pitty and mvo agreed to use a GTK dialog for warning the user (and provide a button for a session restart).

why is everyone still going on about this bug? it was fixed in intrepid, relax.

8.04 was kinda a catastrophe anyway, no ones going to use it when intrepid comes out (unless intrepid is also a catastrophe, which is possible. if these developers keep screwing up, im just moving to fedora. they can start by making the bootloader not extremely ugly on widescreen and square monitors, and stop screwing with the fast-user-switcher-applet in intrepid [see Bug 279939 and Bug 64147])

Yes, after some tests, as Jessie said, this is currently fixed.

In a default ubuntu installation (tried with a fresh updated beta installation), all sudoers are part by default of sambashare group, even if samba package is not setup. I reckon this is because of smbclient default installation, but didn't give a deeper look at that.

So:
- non sudoer will not be part of this group, but as they wouldn't be let to initiate the share by installing samba, there is no problem.
- people who are sudoer (even created after installation time) are in the right group, so, they can initiate the share service and then use it without having to log in again.

I only see two cases when this kind of issue can happened:
* an admin privileges user create another admin user (let's say "admin2") with useradd/adduser command instead of GUI tools. Put him in the admin group (so, with sudoer privileges) but not in the sambashare one. If admin2 wants to initiate the sharing service, he will be able to install automagically samba, but he won't be able to use it without log in again (and so, without notification)
-> Do we want to handle that case? (this is a minor one for advanced user and people who use that may/should know that group addition can be taken into account only when relogin). I checked that the admin profile of the GUI tool is indeed combining the sambashare group for new created admin user and that's the case. A trick would be to test if the current sudoer who initiate the share service is in the sambashare group on its current environment.

* an user wants to share a folder on a machine. He haven't sudoer privileges and so, call an adminstrator, who will use the fast user switching applet (or the one in "System -> Log Out -> Switch user"). He initiates the share, see it works for him, add the user to the sambashare group by the user & group tool (in user properties: "User privileges -> Share files with the local network"). When unloging, revert back to the user session (unlocking it, so, with no session reload) and the addition to the group will not be taken into account. Maybe the administrator would have known that checking the GUI tool added the user to a group if he used the usermod command. But with this GUI tools, even advanced administrator may do not be aware that this action add a user to a group, and that a new login to take that changes effective will be needed.
-> Do we want to handle this case?

Jessie, for the sake of the argument, know that there are people like me who WILL stay on 8.04 until the next LTS release. 8.04 "mostly works", or, at least, its bugs are known to me. That is the distro/version that I am installing on people's computers when I don't want to break them and maintain them every darn 6 months. For a funnier explanation, take a look at http://linuxhaters.blogspot.com/2008/06/evolution-of-ubuntu-user.html , I am currently located at step #5. I don't want to start over my personal Q.A. process over again in 6 months (in this case, 1 month for 8.10). And I figure out that by the next LTS release, epiphany webkit, gdm and the boot time will have attained the kind of reliability I expect.

This was a short explanation of why some people care more than others about bugs that affect Long Term Support releases.

Jessie, it is not at all fixed yet, the problem in this bug report still persists in Intrepid. See comment 50.

Be Alert- the world needs more Lerts

/\^/^\*/^\^/\ There lies in the Ocean an island which is called The Lost. In Charm and all kinds of fertility it far surpasses every other land,  but it is unknown to men.  Now and again it may be found by chance; but if one seeks it, it cannot be found, and therefore it is called The Lost.
Honorius of Autun, De Imagine Mundi, about AD 1130 __________________
When there is nothing to laugh about - laugh on credit

--- On Wed, 10/15/08, Martin Pitt <email address hidden> wrote:
From: Martin Pitt <email address hidden>
Subject: [Bug 212098] Re: "easy" file sharing not notifying about logout/login
To: <email address hidden>
Date: Wednesday, October 15, 2008, 8:08 AM

Jessie, it is not at all fixed yet, the problem in this bug report still
persists in Intrepid. See comment 50.

--
"easy" file sharing not notifying about logout/login
https://bugs.launchpad.net/bugs/212098
You received this bug notification because you are subscribed to Hardy.

Status in “nautilus-share” source package in Ubuntu: Confirmed
Status in nautilus-share in Ubuntu Hardy: Confirmed
Status in nautilus-share in Ubuntu Intrepid: Confirmed
Status in “nautilus-share” source package in Baltix: New

Bug description:
On Hardy Beta>
When trying to share a folder in nautilus it notifies that the samba package is
not installed.
It then installs the package.
When you then try to share the folder again it notifies you that you do not
have privilegies to share files and that you have to contact your
administrator...

This is not really true... The problem is that the user IS already added to the
sambashare user group... but the computer has not been logged out or
restarted... thus it does not notice that you really are allowed to do this.

A warning that you have to restart or log out should be displayed, and NOT that
you dont have the privilegies.

Huh?

umm...okay...

well, i downloaded 8.10 beta and repeated the process and got the expected results. it was fixed in the next release.

everything behaves exactly as expected in respect to installing the sharing services and stuff. i clicked through, and was able to share folders right away. so, mr mazy, i dont know if your just weird, or if something weird happened with u but its fixed dude. chill.

Here is a patch proposition for intrepid after a talk with slangasek (even if a sudoer is in the right group from installation, libpam-smbpasswd has to be installed, and then the user has to authenticate, before that user can be used for authentication to shares).

The only matter is that I based my return on retval, which is the result from synaptic. Even if the download/install failed, the return value is "TRUE", prompting for restarting session… (I can also test if /usr/sbin/smbd is executable, but that will not handle the case where samba installed correctly but not libpam-smbpass).

The last case I described in my previous comment (for an user to ask an administrator to add it to enable sharing right for him, and the admin use "switch user" or ssh to the machine, ie the user didn't reload its environment) is not taken into account by this fix. Steve told that this is far from what we want to adress (making the change as less intrusive as possible) and that's right.
If we want to achieve this, a solution might be :
- retrieve current session user group (if in sambashare group), if not :
  - get the group list from /etc/groups using getwgrent()
  - if the result is that the user is in the sambashare group that probably means that the user didn't reload the session, so, prompt for it -> we can assume that if this is the case, the NTLM hash password will be in the same time generated.

But well this is obviously just a workaround.

In the debdiff (with also a little fix for not destroyed window):

nautilus-share (0.7.2-0ubuntu7) intrepid; urgency=low

  * 02_install_missing_samba.dpatch:
    - prompt for restarting session when installing samba and libpam-smbpass
      to create NTLM password hash (sudoers are already in sambashare group
      in intrepid) (LP: #212098)
    - hidden window was not destroyed if user accepts installing samba

Thanks, Didier! Looks good to me (both patch and testing), uploaded.

This bug was fixed in the package nautilus-share - 0.7.2-0ubuntu7

---------------
nautilus-share (0.7.2-0ubuntu7) intrepid; urgency=low

  * 02_install_missing_samba.dpatch:
    - prompt for restarting session when installing samba and libpam-smbpass
      to create NTLM password hash (sudoers are already in sambashare group
      in intrepid) (LP: #212098)
    - hidden window was not destroyed if user accepts installing samba

 -- Didier Roche <email address hidden> Sat, 18 Oct 2008 14:00:09 +0200

Sorry for the delay, jaunty give me a hard development time :)

Here is an update for hardy. I changed also the maintainer field to core dev as it seemed to be wrongly adressed to motu (rmadison tells me that nautilus-share is in main from hardy).

Sponsored to hardy-proposed, thanks Didier!

Didier, I reverted the core dev -> motu change in debian/control, since the package is in hardy main.

Accepted into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Has anyone tested that the package in hardy-proposed addresses this bug? It would be good to get this through verification this week, so we can include it in the Ubuntu 8.04.2 roll-up.

I confirm the UI that asks for logout works. I tested on a laptop and a desktop, both on up to date Hardy installs.

However it seems rather intrusive to the configuring process, since it doesn't even let the user finish configuring the share - it leaves the share created with default settings, which might not be the intention, and no information on what did or didn't happen.

Is it possible to move the question to after the user clicks on the "save" button, instead of when s/he ticks the share checkbox? This would be far more smooth IMHO.

To other newbies around, here's the procedure I used to confirm. Steps 1-4 are not required, but I wanted to be extra careful:

1- Purge samba, samba-common, libpam-smbpass, and re-install smbclient (which pulls samba-common).
1'- remove the sambashare group
2- Logout, login
3- Try to create a usershare with nautilus, get notified of the need to install packages, accept, install
4- Notice the bug, logout, login, only then sharing is allowed, and shares work

5- remove user account from the sambashare group
6- install updated package
7- logout, login
8- Try to create a usershare with nautilus, get notified of the need to install packages, accept, install
9- get notified that a logout is needed, logout, login, sharing is allowed and shares work

Of course after so many steps, and logouts, I had to make some kind of confusion. Please disregard the part in my first comment about the intrusiveness of the UI - the share is *not* partly created with the 0ubuntu5 package, which is exactly what the bug report is about, duh.

Also, if it wasn't clear, in the above confirmation procedure, steps 1-4 are to confirm the bug, 5-9 to confirm that the fix works.

About the libpam part of the bug, since it suffices to enter the password for an administrative task, does this have to happen *after* the package is installed? I mean, can't the authentication needed for the package installation itself be somehow used for this?

I don't know pam deeply, bug even if it doesn't provide this kind of functionality, gksu should still be cached by the time the installation and configuration finishes, so another call for gksu should silently succeed, taking care of the password sync. Or am I missing something here?

Hum, not sure to understand. You want to use pam to take into account the new user group and silently relaunch the nautilus-share dialog with the same user (so that NTLM password hash is created and the user in the right group), right?

If it's the case, think about a second share that the user wants to do in the same session (without having logout/login). He will not be abled to do that since changing dynamically the user group is not possible (even though, in this case, NTLM password hash will be, I think, created). Keep in mind also that sudoers aren't in the right sambashare group in hardy, contrary to intrepid.

You got it right, both on my sugestion and in the problem with it. What made me think about this was Colin's 29 and 30 comments. Maybe what I'm proposing is overkill, but let me try to clarify a bit.

I think if Bug 238224 gets fixed for hardy, and a one time silent call to gksu makes libpam-smbpass create the NTLM hash, then the whole issue should be fixed for new installs. For old installs, creating sambashare by default and adding the user to it should work, provided the user logs out.

Anyway, if the user upgrades this package, she needs to logout anyway, right? Rolling out a point release seems a reasonable moment to ask the user for a logout. A simple bubble notification should suffice, maybe with a link to a more detailed documentation (with whatever mechanism firefox asks for a restart, and the kernel asks for a reboot).

I'm not sure what would be the most apropriate would be in user-setup, as indicated in bug 238224, or another package. Since the first already has a patch coming, it's obviously easier to go that route. IMHO, the elegant solution would be to do it in nautilus-share, since it's what needs it, and it's pulled in by ubuntu-desktop, so it would be default anyway. But this wouldn't be nice to non-Gnome *buntu derivatives, so samba-common would be my second most elegant sugestion. Again, the patch already exists for user-setup, and it's fine if the result is to get the group created and the first user in it by default.

Yes, providing the default sambashare group + creating NTLM hash on the fly can be a good solution, but as you told, a little big overkill :)

The bubble has already been discussed in desktop team meeting and have been discared. This is enhanced with the goal of having no actions in notifications (cf http://www.markshuttleworth.com/archives/253).

Finally, considering bug 238224, I do not know where it is currently in intrepid (reminder : sudoers are in sambashare group by default), but I think that this bug is adressed in user-setup because it is the current behavior in hardy. Let be consistant.

BTW, everyone agree that the best way will be not to have to do all this trick and switch user group dynamically, but that seems to be quite a complicated and very deep level hack!

Didier,

I think that the "everyone" agreeing that it would be better to switch user groups dynamically probably didn't include many security people, since all the security people I know would run screaming at the suggestion of allowing external modification of the group privileges of a running process. ;)

This bug was fixed in the package nautilus-share - 0.7.2-0ubuntu5.1

---------------
nautilus-share (0.7.2-0ubuntu5.1) hardy-proposed; urgency=low

  * 02_install_missing_samba.dpatch:
   - prompt for restarting session when installing samba to take into account
     sambashare group membership and libpam-smbpass to create NTLM password
     hash (LP: #212098)
   - hidden window was not destroyed if user accepts installing samba

 -- Didier Roche <email address hidden> Thu, 27 Nov 2008 21:18:59 +0100

Sorry Steve, I should have better said "everyone thinks that it should better not to having log out/in again to enable samba sharing", but there seems to be no easily adressable trick to achieve it.
It was what I meant, regardless of technical involvement :)