samba - Aug 2006 - User can't access a share that he has full control of

Hi all,
 
I have noticed that if you create a share to  path lets say
\\dir1\dir2\dir3
And a user lets say u1 has full control on dir3 BUT no control at all on
dir2 then user u1 cannot access the share.
 
Is it right?
 
We have a situation with clients who typically do the following:
Create a share to the root of the file system and  give only to
administrator full control on  for the root path then he creates folders
and apply ACLs to them and then creates shares to map those folders
directly.
Of course, users can access those folders since they don't have search
right on the entire path.
 
Looking at the code reviles that SMB_VFS_STAT is issued with  VUID of
that user and not as root. Meaning that when a new connection is made by
a user and the new process is becoming that VUID and if the uid does not
have search right to all parts of the path, the stat system call will
fail.
 
According to the man page on stat:
"... you do not need any access rights to the file to get information
but you need search rights to all directories named in the path leading
to the file..."
 
Am I missing something here big time?
 
Was it done by purposes?
 
I quickly modified vfs.c and vfs-wraper .c to change to root before stat
or chdir is done and then change back to the original vuid and things
started to work.
Basically, now it works exactly as windows behaving.
 
Meaning a user can access a share that he has rights  to,  even that the
user has no access to all folders leading to that.
 
I also tested the situation on UNIX and emulated the issue in which a
user can do everything going forward from a given directory but of
course can't look or change to directories before.
 
Thanks,
Ephi

On Mon, Aug 21, 2006 at 10:14:02AM -0700, Ephi Dror
wrote:
> Hi all,
>  
> I have noticed that if you create a share to  path lets say
> \\dir1\dir2\dir3
> And a user lets say u1 has full control on dir3 BUT no control at all on
> dir2 then user u1 cannot access the share.
What do you mean by "no control" ? Do you mean "rwx" are set
to "---" ?
If so, then yes this would be expected.
> We have a situation with clients who typically do the following:
> Create a share to the root of the file system and  give only to
> administrator full control on  for the root path then he creates folders
> and apply ACLs to them and then creates shares to map those folders
> directly.
> Of course, users can access those folders since they don't have search
> right on the entire path.
Looks like the Windows admins have left the by default "don't check
traversal permissions" set for all users. Windows does this by
default, POSIX doesn't.
> Was it done by purposes?
It's a POSIX difference.
> I quickly modified vfs.c and vfs-wraper .c to change to root before stat
> or chdir is done and then change back to the original vuid and things
> started to work.
> Basically, now it works exactly as windows behaving.
ie. It's ignoring traversal rights.
> Meaning a user can access a share that he has rights  to,  even that the
> user has no access to all folders leading to that.
I don't want to add this right to Samba. Is there some
reason they can't add the 'x' bit to the top level path ?

Jeremy.

Hi Simo,

Thank you for your reply.

I actually did a little test in which I have two users U1 and U2.
I have a path \\dir1\dir2 in  which I gave access only to administrator
(whom mapped to 0) to dir1 and I gave U1 full control to dir2. Now I
made a share mapping to \\dir1\dir2.

With SAMBA code "as is" not U1 nor U2 can access the share.

With my little patch as I described before U1 can access the share while
U2 can't which is exactly my expectation.
Also this is how my "windows" customers  can be setup for running home
directories.

Our customers are too much "windows" oriented and prefer setting files
securities (Acls) via what they know best which is file properties and
less via smb.conf in which we are the champions...

Also, they told me that they typically creating some kind of an
"admin"
share to the root of the file system in which only restricted  users and
group can have access and then they create all their wonderful folders
and stuff in which they use ACLs to manipulate access.
So they create different shares pointing to different paths in the file
system but since the "admin" share that point to the root gave access
only to administrator for example, that's how they run into the problem
with our SAMBA.

So far I can't see it as a problem. 

Cheers,
Ephi

-----Original Message-----
From: simo [mailto:idra@samba.org]
Sent: Monday, August 21, 2006 11:41 AM
To: Jeremy Allison
Cc: Ephi Dror; samba@lists.samba.org
Subject: Re: [Samba] User can't access a share that he has full control
of

On Mon, 2006-08-21 at 11:12 -0700, Jeremy Allison wrote:
> > 3. If I do this change for our customers, is there any security 
> > issue here that I haven't thought about?
> 
> Yes, it's a security hole (IMHO). It completely bypasses security for 
> a path. There might be things an attacker could do with this (don't 
> have time right now to think up evil scenarious but I'm sure there are
> some :-).
An easy example is accessing other users home directories where the user
target has a 700 permission on his home directory specifically set to
keep out other users. It is a common scenario on unix environments.

Simo.

--
Simo Sorce
Samba Team GPL Compliance Officer
email: idra@samba.org
http://samba.org

Hi All,

One more point if I may:

I see that Samba currently consider it as security "problem", not a
security "benefit". 

However, frequently there are sub trees that need to be accessed by a
particular user, and with the current semantics, you need to give more
permissions than you might otherwise need to for the directories above
the sub tree. The whole point of a share (or an NFS export) on a server
is to be a direct point of access to clients.

I didn't see how my change violate any POSIX security. It sounds to me
so logic to give user permissions only from mount/export points and not
for any directory leading to mount point.

Cheers,
Ephi



-----Original Message-----
From: Ephi Dror 
Sent: Monday, August 21, 2006 12:11 PM
To: samba@lists.samba.org
Cc: 'Jeremy Allison'; 'idra@samba.org'
Subject: Re: [Samba] User can't access a share that he has full control
of


Hi Simo,

Thank you for your reply.

I actually did a little test in which I have two users U1 and U2.
I have a path \\dir1\dir2 in  which I gave access only to administrator
(whom mapped to 0) to dir1 and I gave U1 full control to dir2. Now I
made a share mapping to \\dir1\dir2.

With SAMBA code "as is" not U1 nor U2 can access the share.

With my little patch as I described before U1 can access the share while
U2 can't which is exactly my expectation.
Also this is how my "windows" customers  can be setup for running home
directories.

Our customers are too much "windows" oriented and prefer setting files
securities (Acls) via what they know best which is file properties and
less via smb.conf in which we are the champions...

Also, they told me that they typically creating some kind of an
"admin"
share to the root of the file system in which only restricted  users and
group can have access and then they create all their wonderful folders
and stuff in which they use ACLs to manipulate access.
So they create different shares pointing to different paths in the file
system but since the "admin" share that point to the root gave access
only to administrator for example, that's how they run into the problem
with our SAMBA.

So far I can't see it as a problem. 

Cheers,
Ephi

-----Original Message-----
From: simo [mailto:idra@samba.org]
Sent: Monday, August 21, 2006 11:41 AM
To: Jeremy Allison
Cc: Ephi Dror; samba@lists.samba.org
Subject: Re: [Samba] User can't access a share that he has full control
of

On Mon, 2006-08-21 at 11:12 -0700, Jeremy Allison wrote:
> > 3. If I do this change for our customers, is there any security 
> > issue here that I haven't thought about?
> 
> Yes, it's a security hole (IMHO). It completely bypasses security for 
> a path. There might be things an attacker could do with this (don't 
> have time right now to think up evil scenarious but I'm sure there are
> some :-).
An easy example is accessing other users home directories where the user
target has a 700 permission on his home directory specifically set to
keep out other users. It is a common scenario on unix environments.

Simo.

--
Simo Sorce
Samba Team GPL Compliance Officer
email: idra@samba.org
http://samba.org