Hi,
I'm new to CentOS and also on the list, since I usually work with Debian. My problem is as follows:
I have a NAS where users connect to do their backups. Each user has a folder shared where only he can enter. Multiple users get connected from a CentOS 5.7 to the NAS, each in its shared folder.
I connect to the NAS by entering the login, password and shared folder of user A (here I connect through SMB port 445) and I get disconnected by removing the volume. I re-connect in the same way with the user B and then disconnect.
Now if I connect with any user without entering the shared folder (I get a netbios connection to port 139) I can enter to the shared folder of user A and B without entering their credentials.
A netstat -an shows me a connection to port 139 and 445 per user. After a while (too I think) connections over ports 445 and 139 are automatically cuted and I have to authenticate again.
How I can force always the request of login and password?
Thanks in advance.
Le 23/11/2011 12:11, Guitart Francesc a écrit :
Hi,
I'm new to CentOS and also on the list, since I usually work with Debian. My problem is as follows:
I have a NAS where users connect to do their backups. Each user has a folder shared where only he can enter. Multiple users get connected from a CentOS 5.7 to the NAS, each in its shared folder.
I connect to the NAS by entering the login, password and shared folder of user A (here I connect through SMB port 445) and I get disconnected by removing the volume. I re-connect in the same way with the user B and then disconnect.
Now if I connect with any user without entering the shared folder (I get a netbios connection to port 139) I can enter to the shared folder of user A and B without entering their credentials.
In fact I have explained wrong. This time I log in from any window File
Go to .. (I don't know the exact translation in english cause I'm in
one french computer) and type smb://nas_name.
I can access to the NAS and I can enter all the shared folders of all users that I previously had been logged from "Connect to server"
Thanks again.
On Wed, Nov 23, 2011 at 7:59 PM, Guitart Francesc francesc.guitart@enise.fr wrote:
In fact I have explained wrong. This time I log in from any window File >> Go to .. (I don't know the exact translation in english cause I'm in one french computer) and type smb://nas_name.
I can access to the NAS and I can enter all the shared folders of all users that I previously had been logged from "Connect to server"
1) How do you arrange the directory structures of the share? Is it like: /data/share/userA /data/share/userB ?
2). How do you setup the share in smb.conf? Is it like: [data] path=/data/share ?
If yes to the above.... the only protection you can give is by filesystem permission and ownership, not through samba.
El vie, 25-11-2011 a las 19:11 +0800, Fajar Priyanto escribió:
On Wed, Nov 23, 2011 at 7:59 PM, Guitart Francesc francesc.guitart@enise.fr wrote:
In fact I have explained wrong. This time I log in from any window File
Go to .. (I don't know the exact translation in english cause I'm in
one french computer) and type smb://nas_name.
I can access to the NAS and I can enter all the shared folders of all users that I previously had been logged from "Connect to server"
- How do you arrange the directory structures of the share?
Is it like: /data/share/userA /data/share/userB ?
/data/shareA >> where only the userA have access. /data/shareB >> where only the userB have access.
2). How do you setup the share in smb.conf? Is it like: [data] path=/data/share ?
The shares are in the NAS so I don't have any smb.conf to configure.
If yes to the above.... the only protection you can give is by filesystem permission and ownership, not through samba.
Thanks for your answer.
On 11/23/11 3:11 AM, Guitart Francesc wrote:
here I connect through SMB port 445
why in dogs name are you using SMB, a Microsoft Windows protocol, for Unix to NAS file sharing? Unix systems should use NFS for file sharing. netbios is a tangled mess of poorly planned protocols with extensions on the extensions, and warts on the warts (ports 137/138/139 were old NetBIOS, using NetBIOS-over-TCP aka NBT as the transport, while port 445 is the newer native CIFS protocol introduced around Windows2000 time).
with NFS, you'd mount the backup directory somewhere, like /nfsbackups just once at bootup time and each user would have their own directory in it, /nfsbackusp/fred (or whatever) and only have read/write access to that directory, managed via standard unix style chmod, chown ...
El mié, 23-11-2011 a las 10:50 -0800, John R Pierce escribió:
On 11/23/11 3:11 AM, Guitart Francesc wrote:
here I connect through SMB port 445
why in dogs name are you using SMB, a Microsoft Windows protocol, for Unix to NAS file sharing? Unix systems should use NFS for file sharing. netbios is a tangled mess of poorly planned protocols with extensions on the extensions, and warts on the warts (ports 137/138/139 were old NetBIOS, using NetBIOS-over-TCP aka NBT as the transport, while port 445 is the newer native CIFS protocol introduced around Windows2000 time).
with NFS, you'd mount the backup directory somewhere, like /nfsbackups just once at bootup time and each user would have their own directory in it, /nfsbackusp/fred (or whatever) and only have read/write access to that directory, managed via standard unix style chmod, chown ...
Thanks for your comment. You're right, but the problem arises with your solution is that all users are using the CentOS machine login locally with the same user. So, correct me if I'm wrong, I think I can not mount the volume for each user without the others have access.
On the other hand, what maneges SMB passwords to tell don't remember it? ¿PAM, smbclient/smbpasswd, gnome-vfs?
On Fri, 25 Nov 2011, Guitart Francesc wrote:
Thanks for your comment. You're right, but the problem arises with your solution is that all users are using the CentOS machine login locally with the same user. So, correct me if I'm wrong, I think I can not mount the volume for each user without the others have access.
Don't correct one mistake by making another. Once you've got all users sharing the same user account, you might as well throw away security anyway. Unless you're saying that this account is something like guest with no password where the account is completely deleted when you logout.
jh
El vie, 25-11-2011 a las 11:03 +0000, John Hodrien escribió:
On Fri, 25 Nov 2011, Guitart Francesc wrote:
Thanks for your comment. You're right, but the problem arises with your solution is that all users are using the CentOS machine login locally with the same user. So, correct me if I'm wrong, I think I can not mount the volume for each user without the others have access.
Don't correct one mistake by making another. Once you've got all users sharing the same user account, you might as well throw away security anyway. Unless you're saying that this account is something like guest with no password where the account is completely deleted when you logout.
I'm talking of one local account in the CentOS machine without permissions to the network (this is why i'm trying to give them acces to the NAS as your own network user account) where the users run a calculation system.
On 11/26/11 2:42 AM, Guitart Francesc wrote:
I'm talking of one local account in the CentOS machine without permissions to the network (this is why i'm trying to give them acces to the NAS as your own network user account) where the users run a calculation system.
if all the user processes are running as the same user ID, how do you expect the file system to know what user is supposed to have access to which share? what you're asking for is physically impossible. once user "A" logged on as unix user X opens his user 'ShareA', *all* processes running as unix user "X" will have access to it. if you thought it worked differently on Debian, you were wrong.
Le 26/11/2011 20:01, John R Pierce a écrit :
On 11/26/11 2:42 AM, Guitart Francesc wrote:
I'm talking of one local account in the CentOS machine without permissions to the network (this is why i'm trying to give them acces to the NAS as your own network user account) where the users run a calculation system.
if all the user processes are running as the same user ID, how do you expect the file system to know what user is supposed to have access to which share? what you're asking for is physically impossible. once user "A" logged on as unix user X opens his user 'ShareA', *all* processes running as unix user "X" will have access to it. if you thought it worked differently on Debian, you were wrong.
Sorry, maybe I haven't been clear. What I can do with Debian is to forget the SMB password every time I get connect to NAS, in such a way several network users can use the same local account. While, if I understand correctly, you are talking on the assumption of one NFS connection.
Thanks again.
On Mon, Nov 28, 2011 at 4:22 PM, Guitart Francesc francesc.guitart@enise.fr wrote:
if all the user processes are running as the same user ID, how do you expect the file system to know what user is supposed to have access to which share? what you're asking for is physically impossible. once user "A" logged on as unix user X opens his user 'ShareA', *all* processes running as unix user "X" will have access to it. if you thought it worked differently on Debian, you were wrong.
Sorry, maybe I haven't been clear. What I can do with Debian is to forget the SMB password every time I get connect to NAS, in such a way several network users can use the same local account. While, if I understand correctly, you are talking on the assumption of one NFS connection.
I don't get it. 1. Why use shared account? 2. If you are using the same account, how can you prevent user from accessing each other's folder? /data/userA /data/userB The above ownership and permission won't do any good.
Le 28/11/2011 09:27, Fajar Priyanto a écrit :
On Mon, Nov 28, 2011 at 4:22 PM, Guitart Francesc francesc.guitart@enise.fr wrote:
if all the user processes are running as the same user ID, how do you expect the file system to know what user is supposed to have access to which share? what you're asking for is physically impossible. once user "A" logged on as unix user X opens his user 'ShareA', *all* processes running as unix user "X" will have access to it. if you thought it worked differently on Debian, you were wrong.
Sorry, maybe I haven't been clear. What I can do with Debian is to forget the SMB password every time I get connect to NAS, in such a way several network users can use the same local account. While, if I understand correctly, you are talking on the assumption of one NFS connection.
I don't get it.
- Why use shared account?
Good question. This is a server that was already running when I started working here. I don't know the software that has installed and prefer not to touch a lot. That's the only reason I have for to continue using one local user account shared by several people.
- If you are using the same account, how can you prevent user from
accessing each other's folder? /data/userA /data/userB The above ownership and permission won't do any good.
I use the same local account to log into the machine. It is when I try to connect to the NAS that I use different user accounts. After I log out and continue to be able to access the resources of all users who have connected to the NAS above.
In contrast, with Debian, I get connected to NAS asking me the password, after I get disconnect and when I try to reconnect I have to tape the password again.
On Mon, Nov 28, 2011 at 7:40 AM, Guitart Francesc francesc.guitart@enise.fr wrote:
- Why use shared account?
Good question. This is a server that was already running when I started working here. I don't know the software that has installed and prefer not to touch a lot. That's the only reason I have for to continue using one local user account shared by several people.
- If you are using the same account, how can you prevent user from
accessing each other's folder? /data/userA /data/userB The above ownership and permission won't do any good.
I use the same local account to log into the machine. It is when I try to connect to the NAS that I use different user accounts. After I log out and continue to be able to access the resources of all users who have connected to the NAS above.
In contrast, with Debian, I get connected to NAS asking me the password, after I get disconnect and when I try to reconnect I have to tape the password again.
So what happened when all the users log in at once to the shared account? I'd expect the mounted NAS to be available to everyone regardless of who mounted it first. And if that's the case, why does it matter if that continues to be true after someone logs out?
Le 28/11/2011 14:56, Les Mikesell a écrit :
On Mon, Nov 28, 2011 at 7:40 AM, Guitart Francesc francesc.guitart@enise.fr wrote:
- Why use shared account?
Good question. This is a server that was already running when I started working here. I don't know the software that has installed and prefer not to touch a lot. That's the only reason I have for to continue using one local user account shared by several people.
- If you are using the same account, how can you prevent user from
accessing each other's folder? /data/userA /data/userB The above ownership and permission won't do any good.
I use the same local account to log into the machine. It is when I try to connect to the NAS that I use different user accounts. After I log out and continue to be able to access the resources of all users who have connected to the NAS above.
In contrast, with Debian, I get connected to NAS asking me the password, after I get disconnect and when I try to reconnect I have to tape the password again.
So what happened when all the users log in at once to the shared account? I'd expect the mounted NAS to be available to everyone regardless of who mounted it first. And if that's the case, why does it matter if that continues to be true after someone logs out?
I don't understand what you try to say me but I have the feeling that I did not explained well. I will try again:
The CentOS computer logs on locally always with the same user: LocalUser
Once I logged on CentOS with LocalUser user:
I connect to the NAS (\NAS\sharedA) from "Connect to Server">> "Shared Windows" as userA.
I disconnected from the NAS as userA ejecting the volume on the Desktop.
I connect to the NAS (\NAS\sharedB) from "Connect to Server">> "Shared Windows" as userB.
I disconnected from the NAS as userB ejecting the volume on the Desktop.
Now, from any window of Gnome Desktop I write smb://ip-nas/ and I have access to sharedA and sharedB.
In fact, if I do netstat -an I can see four connections to the NAS, two for every user (139 tcp and 445 tcp) what are saying I'm not really disconnected from the NAS.
How can I really disconnect from NAS? Or how can I force the password being asked every time I try to access to one shared ressource as happens in Debian?
On Mon, Nov 28, 2011 at 8:57 AM, Guitart Francesc francesc.guitart@enise.fr wrote:
So what happened when all the users log in at once to the shared account? I'd expect the mounted NAS to be available to everyone regardless of who mounted it first. And if that's the case, why does it matter if that continues to be true after someone logs out?
I don't understand what you try to say me but I have the feeling that I did not explained well. I will try again:
Linux is a multiuser system and there is nothing special about its local console. Users can log in over the network with a variety of methods, either with command line access or a GUI desktop. You may not be using that capability - or perhaps you just don't know that others are using it. The Gnome desktop is not happy with multiple instances running as the same user, though, so perhaps no one is doing that.
The CentOS computer logs on locally always with the same user: LocalUser
Once I logged on CentOS with LocalUser user:
I connect to the NAS (\NAS\sharedA) from "Connect to Server">> "Shared Windows" as userA.
I disconnected from the NAS as userA ejecting the volume on the Desktop.
I connect to the NAS (\NAS\sharedB) from "Connect to Server">> "Shared Windows" as userB.
This is a little bit different from normal mounting - that is a feature built into the Nautilus file manager. It will be able to copy/paste/edit//execute files from the remote share as internal operations and but it doesn't make them available as part of the file system. In this case access would be limited to the instance of Nautilus that made the connection, much like it would with smbclient.
I disconnected from the NAS as userB ejecting the volume on the Desktop.
Now, from any window of Gnome Desktop I write smb://ip-nas/ and I have access to sharedA and sharedB.
In fact, if I do netstat -an I can see four connections to the NAS, two for every user (139 tcp and 445 tcp) what are saying I'm not really disconnected from the NAS.
How can I really disconnect from NAS? Or how can I force the password being asked every time I try to access to one shared ressource as happens in Debian?
Logging out of the Gnome desktop should do it, but the whole concept seems very wrong. Even if all the users are working at the same console, they should have different logins.
On Mon, 28 Nov 2011, Les Mikesell wrote:
Logging out of the Gnome desktop should do it, but the whole concept seems very wrong. Even if all the users are working at the same console, they should have different logins.
+1
If you don't have separate logins, or delete and fully recreate the account inbetween logins, you're only pretending to have any degree of security.
jh
On Monday, November 28, 2011 11:23:57 AM Les Mikesell wrote:
Even if all the users are working at the same console, they should have different logins.
You know, reading through this thread is frustrating.
Frustrating in that the OP's question has yet to be answered; instead, yet again, the OP's methods are being questioned.
The OP is doing things a particular way for a reason; a useful answer is better than questioning the OP's methods, IMO.
And while I wouldn't do it the way the OP is doing it, that's the OP's business, it would be nice to see people give people more 'benefit of the doubt' rather than assume that because the OP isn't doing it the 'regular way' that the OP doesn't know what he's doing. He may have neither the time nor the budget to:
1.) Retool the login user; 2.) Retrain users to login as their own user; 3.) Set up the authentication necessary to do it 'right' instead of the way that seems to be working for him.
So, it seems the question boils down to: In a shared local login account situation, how can one set up Nautilus to forget SMB credentials between certain times?
Whether you agree with the setup or not is immaterial; this is the way the OP needs to do things in his situation.
TMTOWTDI
Lamar Owen wrote:
On Monday, November 28, 2011 11:23:57 AM Les Mikesell wrote:
Even if all the users are working at the same console, they should have different logins.
You know, reading through this thread is frustrating.
Yup.
Frustrating in that the OP's question has yet to be answered; instead, yet again, the OP's methods are being questioned.
<snip>
way' that the OP doesn't know what he's doing. He may have neither the time nor the budget to:
<snip> You missed one: he may not have the authority to do so.
mark
On Mon, Nov 28, 2011 at 11:50 AM, Lamar Owen lowen@pari.edu wrote:
On Monday, November 28, 2011 12:40:59 PM m.roth@5-cent.us wrote:
You missed one: he may not have the authority to do so.
Yep, I did. I keep forgetting that others don't have the flexibility that I do, so thanks for that reminder.
None of which justifies someone else helping to continue a misguided and insecure practice... If it is a matter of policy, let them take the hit themselves.
Les Mikesell wrote:
On Mon, Nov 28, 2011 at 11:50 AM, Lamar Owen lowen@pari.edu wrote:
On Monday, November 28, 2011 12:40:59 PM m.roth@5-cent.us wrote:
You missed one: he may not have the authority to do so.
Yep, I did. I keep forgetting that others don't have the flexibility that I do, so thanks for that reminder.
None of which justifies someone else helping to continue a misguided and insecure practice... If it is a matter of policy, let them take the hit themselves.
Les, that's rude and thoughtless. The OP isn't "guilty" of following it, he may be doing what he's told to do. Now, maybe, you're in such an employment that if you disapprove of the way something's done, you just take a hike. The rest of us, in the middle of a bloody depression, hang onto our jobs as hard as we can. We may do our best to lead management to better practice, but when they say, "do it my way", we're stuck doing it that way, or are in danger of being told to take a hike.
Is that the hit you offer the OP?
mark
On Monday, November 28, 2011 01:15:30 PM Les Mikesell wrote:
None of which justifies someone else helping to continue a misguided and insecure practice...
Not all systems are Internet connected, and not all sites need the same security; one size does not fit all.
In the OP, we have a basic set of data against which a question was asked: 1.) The OP has a NAS (perhaps only able to do SMB for all we know); 2.) The OP has inherited a system with an undefined number of users who all share a login on a workstation (which actually is fairly common on the floor of a factory, just to mention one instance of which I have direct knowledge); 3.) The system as described allows each user to have a semi-private fileshare; 4.) The OP wants to disable credential caching for SMB fileshares from the desktop (at least that's how it sounds).
The request embodied by 4 is not unreasonable, and should be answerable.
To the OP; see the opposite of your problem in this Ubuntu bug report: https://bugs.launchpad.net/gnome-keyring/+bug/67189
Perhaps the GNOME keyring settings can be twiddled to make it not remember SMB credentials? Don't know directly, as I'm a KDE user (but the KDE wallet has similar 'features' that seem to be inconsistent from update to update.....). But if I were to have the OP's issue that's what I'd look at first.
If it is a matter of policy, let them take the hit themselves.
Or how about anyone who is not willing to try to actually answer the question simply not unnecessarily reply? Or reply privately instead. I can't count the times I've searched for the answer to an arcane issue and come up with hundreds of useless 'you shouldn't do it that way so I refuse to answer the question but I'm going to post anyway and you can't make me stop' threads and one or two actual answers; having the useless rant threads out there makes it more difficult to find solutions in the archives.
Because the fact of the matter is, no matter what you do, someone out there thinks what you're doing is stupid.
Le 28/11/2011 20:49, Lamar Owen a écrit :
On Monday, November 28, 2011 01:15:30 PM Les Mikesell wrote:
None of which justifies someone else helping to continue a misguided and insecure practice...
Not all systems are Internet connected, and not all sites need the same security; one size does not fit all.
In the OP, we have a basic set of data against which a question was asked: 1.) The OP has a NAS (perhaps only able to do SMB for all we know); 2.) The OP has inherited a system with an undefined number of users who all share a login on a workstation (which actually is fairly common on the floor of a factory, just to mention one instance of which I have direct knowledge); 3.) The system as described allows each user to have a semi-private fileshare; 4.) The OP wants to disable credential caching for SMB fileshares from the desktop (at least that's how it sounds).
The request embodied by 4 is not unreasonable, and should be answerable.
To the OP; see the opposite of your problem in this Ubuntu bug report: https://bugs.launchpad.net/gnome-keyring/+bug/67189
Thanks for the link. Following the trail I could see several bugs reported in bugzilla.gnome.org. The problem I have is related to the version of Gnome:
CentOS 5.7: Gnome 2.16 >> Does not work as I expect. Debian 6: Gnome 2.30.2 >> Works as I expect. Center 6: Gnome 2.28.2 >> Works as I expect.
Thank you all for your responses.
Le 28/11/2011 17:23, Les Mikesell a écrit :
(...)
This is a little bit different from normal mounting - that is a feature built into the Nautilus file manager. It will be able to copy/paste/edit//execute files from the remote share as internal operations and but it doesn't make them available as part of the file system. In this case access would be limited to the instance of Nautilus that made the connection, much like it would with smbclient.
This explanation links perfectly with what happens to me, now I understand a little better.
I disconnected from the NAS as userB ejecting the volume on the Desktop.
Now, from any window of Gnome Desktop I write smb://ip-nas/ and I have access to sharedA and sharedB.
In fact, if I do netstat -an I can see four connections to the NAS, two for every user (139 tcp and 445 tcp) what are saying I'm not really disconnected from the NAS.
How can I really disconnect from NAS? Or how can I force the password being asked every time I try to access to one shared ressource as happens in Debian?
Logging out of the Gnome desktop should do it, but the whole concept seems very wrong. Even if all the users are working at the same console, they should have different logins.
Yes, I had alredy tested and it works, logging out of Gnome disconnect from NAS but also kill processes running when I just wanted to release a volume SMB.
I know it's not a good solution from the point of view of security, but they work like that for a long time and I just recently work here. Furthermore I'm not familiar with this machine and the services that provide. Also looks set to be replaced within a couple of months, so I did not want to spend much time, changing the way users work, and risking of breaking something in a compute server used constantly with something that has a period of life so short.
On 11/28/11 12:22 AM, Guitart Francesc wrote:
Sorry, maybe I haven't been clear. What I can do with Debian is to forget the SMB password every time I get connect to NAS, in such a way several network users can use the same local account. While, if I understand correctly, you are talking on the assumption of one NFS connection.
are you using smb mounts, or just smbclient with 'get/put' ftp-style file access?
Le 28/11/2011 09:36, John R Pierce a écrit :
On 11/28/11 12:22 AM, Guitart Francesc wrote:
Sorry, maybe I haven't been clear. What I can do with Debian is to forget the SMB password every time I get connect to NAS, in such a way several network users can use the same local account. While, if I understand correctly, you are talking on the assumption of one NFS connection.
are you using smb mounts, or just smbclient with 'get/put' ftp-style file access?
I don't know, how I can check it? What are using when you connect by "Connect to server" >> "Shared Windows" ?
A priori I would respond smb mounts but if I check it with "mount" in Terminal when connected to the NAS I don't see nothing.
On 11/28/11 5:51 AM, Guitart Francesc wrote:
are you using smb mounts, or just smbclient with 'get/put' ftp-style
file access?
I don't know, how I can check it? What are using when you connect by "Connect to server">> "Shared Windows" ?
no idea, I hardly ever use gnome.
On Sat, 26 Nov 2011, Guitart Francesc wrote:
El vie, 25-11-2011 a las 11:03 +0000, John Hodrien escribió:
On Fri, 25 Nov 2011, Guitart Francesc wrote:
Thanks for your comment. You're right, but the problem arises with your solution is that all users are using the CentOS machine login locally with the same user. So, correct me if I'm wrong, I think I can not mount the volume for each user without the others have access.
Don't correct one mistake by making another. Once you've got all users sharing the same user account, you might as well throw away security anyway. Unless you're saying that this account is something like guest with no password where the account is completely deleted when you logout.
I'm talking of one local account in the CentOS machine without permissions to the network (this is why i'm trying to give them acces to the NAS as your own network user account) where the users run a calculation system.
I'm fairly sure I get what you're describing. Problem is, given you've got a single shared account on the CentOS machine, any user is free to run any old key logger or put modified binaries in the path. It's just plain not secure, and it doesn't matter that the machine has now permissions to the network.
Shared accounts are a bad idea from almost every angle.
jh
On Tue, Nov 29, 2011 at 4:03 AM, Lamar Owen lowen@pari.edu wrote:
On Wednesday, November 23, 2011 06:11:31 AM Guitart Francesc wrote:
How I can force always the request of login and password?
In System -> Administration -> Authentication, 'Options' tab, is 'Cache User Information' checked?
I think Centos Nautilus and Ubuntu should have 'forget password immediately"? In other case you can force it to do that by: killall -HUP gnome-vfs-daemon
-
Fajar Priyanto -
Guitart Francesc -
John Hodrien -
John R Pierce -
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us