* Resolved merge conflicts in next-creds
@ 2008-08-10 23:57 James Morris
2008-08-11 0:16 ` Stephen Rothwell
2008-08-11 14:51 ` Steven French
0 siblings, 2 replies; 9+ messages in thread
From: James Morris @ 2008-08-10 23:57 UTC (permalink / raw)
To: David Howells
Cc: Stephen Rothwell, linux-kernel, David S. Miller, Steve French
I manually resolved the following conflicts in
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next-creds
when merging with latest Linus. (This branch holds the creds API changes
from David Howells and is being pulled into linux-next).
commit 293f28d5b02efe4504d5976f6f5889458ed56539
Merge: ea40dc0... 796aade...
Author: James Morris <jmorris@namei.org>
Date: Mon Aug 11 09:22:10 2008 +1000
Merge branch 'master' into next-creds
Conflicts:
arch/sparc64/kernel/sys_sparc32.c
fs/cifs/dir.c
fs/cifs/inode.c
---
The Sparc conflicts were from a bunch of code which Adrian Bunk removed in
ea771bd51c3b9b9683860515d93e6155a345fa2f, and should not be able to cause
problems.
The CIFS conflicts were collisions with API changes. I'm not sure how
best to extract this information from git. 'git-rerere' doesn't seem to
do anythig, even with:
$ git-config --list
rerere.enabled=1
A git-show on the merge ID produces the following:
commit 293f28d5b02efe4504d5976f6f5889458ed56539
Merge: ea40dc0... 796aade...
Author: James Morris <jmorris@namei.org>
Date: Mon Aug 11 09:22:10 2008 +1000
Merge branch 'master' into next-creds
Conflicts:
arch/sparc64/kernel/sys_sparc32.c
fs/cifs/dir.c
fs/cifs/inode.c
Signed-off-by: James Morris <jmorris@namei.org>
diff --cc fs/cifs/dir.c
index a2d4a2b,e962e75..2f02c52
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@@ -226,23 -226,28 +226,28 @@@ cifs_create(struct inode *inode, struc
/* If Open reported that we actually created a file
then we now have to set the mode if possible */
if ((pTcon->unix_ext) && (oplock & CIFS_CREATE_ACTION)) {
+ struct cifs_unix_set_info_args args = {
+ .mode = mode,
+ .ctime = NO_CHANGE_64,
+ .atime = NO_CHANGE_64,
+ .mtime = NO_CHANGE_64,
+ .device = 0,
+ };
+
if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SET_UID) {
- CIFSSMBUnixSetPerms(xid, pTcon, full_path, mode,
- (__u64)current_fsuid(),
- (__u64)current_fsgid(),
- 0 /* dev */,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
- args.uid = (__u64) current->fsuid;
++ args.uid = (__u64) current_fsuid();
+ if (inode->i_mode & S_ISGID)
+ args.gid = (__u64) inode->i_gid;
+ else
- args.gid = (__u64) current->fsgid;
++ args.gid = (__u64) current_fsgid();
} else {
- CIFSSMBUnixSetPerms(xid, pTcon, full_path, mode,
- (__u64)-1,
- (__u64)-1,
- 0 /* dev */,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
+ args.uid = NO_CHANGE_64;
+ args.gid = NO_CHANGE_64;
}
+ CIFSSMBUnixSetInfo(xid, pTcon, full_path, &args,
+ cifs_sb->local_nls,
+ cifs_sb->mnt_cifs_flags &
+ CIFS_MOUNT_MAP_SPECIAL_CHR);
} else {
/* BB implement mode setting via Windows security
descriptors e.g. */
@@@ -266,8 -271,13 +271,13 @@@
if ((oplock & CIFS_CREATE_ACTION) &&
(cifs_sb->mnt_cifs_flags &
CIFS_MOUNT_SET_UID)) {
- newinode->i_uid = current->fsuid;
+ newinode->i_uid = current_fsuid();
- newinode->i_gid = current_fsgid();
+ if (inode->i_mode & S_ISGID)
+ newinode->i_gid =
+ inode->i_gid;
+ else
+ newinode->i_gid =
- current->fsgid;
++ current_fsgid();
}
}
}
@@@ -357,21 -367,24 +367,24 @@@ int cifs_mknod(struct inode *inode, str
if (full_path == NULL)
rc = -ENOMEM;
else if (pTcon->unix_ext) {
- mode &= ~current->fs->umask;
+ struct cifs_unix_set_info_args args = {
+ .mode = mode & ~current->fs->umask,
+ .ctime = NO_CHANGE_64,
+ .atime = NO_CHANGE_64,
+ .mtime = NO_CHANGE_64,
+ .device = device_number,
+ };
if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SET_UID) {
- rc = CIFSSMBUnixSetPerms(xid, pTcon, full_path,
- mode, (__u64)current_fsuid(),
- (__u64)current_fsgid(),
- device_number, cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
- args.uid = (__u64) current->fsuid;
- args.gid = (__u64) current->fsgid;
++ args.uid = (__u64) current_fsuid();
++ args.gid = (__u64) current_fsgid();
} else {
- rc = CIFSSMBUnixSetPerms(xid, pTcon,
- full_path, mode, (__u64)-1, (__u64)-1,
- device_number, cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
+ args.uid = NO_CHANGE_64;
+ args.gid = NO_CHANGE_64;
}
+ rc = CIFSSMBUnixSetInfo(xid, pTcon, full_path,
+ &args, cifs_sb->local_nls,
+ cifs_sb->mnt_cifs_flags &
+ CIFS_MOUNT_MAP_SPECIAL_CHR);
if (!rc) {
rc = cifs_get_inode_info_unix(&newinode, full_path,
diff --cc fs/cifs/inode.c
index 4857f15,28a2209..e18ce20
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@@ -984,25 -985,34 +985,34 @@@ mkdir_get_info
* failed to get it from the server or was set bogus */
if ((direntry->d_inode) && (direntry->d_inode->i_nlink < 2))
direntry->d_inode->i_nlink = 2;
+
mode &= ~current->fs->umask;
+ /* must turn on setgid bit if parent dir has it */
+ if (inode->i_mode & S_ISGID)
+ mode |= S_ISGID;
+
if (pTcon->unix_ext) {
+ struct cifs_unix_set_info_args args = {
+ .mode = mode,
+ .ctime = NO_CHANGE_64,
+ .atime = NO_CHANGE_64,
+ .mtime = NO_CHANGE_64,
+ .device = 0,
+ };
if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SET_UID) {
- CIFSSMBUnixSetPerms(xid, pTcon, full_path,
- mode,
- (__u64)current_fsuid(),
- (__u64)current_fsgid(),
- 0 /* dev_t */,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
- args.uid = (__u64)current->fsuid;
++ args.uid = (__u64)current_fsuid();
+ if (inode->i_mode & S_ISGID)
+ args.gid = (__u64)inode->i_gid;
+ else
- args.gid = (__u64)current->fsgid;
++ args.gid = (__u64)current_fsgid();
} else {
- CIFSSMBUnixSetPerms(xid, pTcon, full_path,
- mode, (__u64)-1,
- (__u64)-1, 0 /* dev_t */,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
+ args.uid = NO_CHANGE_64;
+ args.gid = NO_CHANGE_64;
}
+ CIFSSMBUnixSetInfo(xid, pTcon, full_path, &args,
+ cifs_sb->local_nls,
+ cifs_sb->mnt_cifs_flags &
+ CIFS_MOUNT_MAP_SPECIAL_CHR);
} else {
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_CIFS_ACL) &&
(mode & S_IWUGO) == 0) {
@@@ -1023,9 -1033,13 +1033,13 @@@
if (cifs_sb->mnt_cifs_flags &
CIFS_MOUNT_SET_UID) {
direntry->d_inode->i_uid =
- current->fsuid;
+ current_fsuid();
- direntry->d_inode->i_gid =
- current_fsgid();
+ if (inode->i_mode & S_ISGID)
+ direntry->d_inode->i_gid =
+ inode->i_gid;
+ else
+ direntry->d_inode->i_gid =
- current->fsgid;
++ current_fsgid();
}
}
}
----
The code compiles ok -- let me know if anything seems wrong.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Resolved merge conflicts in next-creds
2008-08-10 23:57 Resolved merge conflicts in next-creds James Morris
@ 2008-08-11 0:16 ` Stephen Rothwell
2008-08-11 5:35 ` Stephen Rothwell
2008-08-11 14:51 ` Steven French
1 sibling, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2008-08-11 0:16 UTC (permalink / raw)
To: James Morris; +Cc: David Howells, linux-kernel, David S. Miller, Steve French
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
Hi James,
On Mon, 11 Aug 2008 09:57:44 +1000 (EST) James Morris <jmorris@namei.org> wrote:
>
> I manually resolved the following conflicts in
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next-creds
>
> when merging with latest Linus. (This branch holds the creds API changes
> from David Howells and is being pulled into linux-next).
Thanks for that.
> The CIFS conflicts were collisions with API changes. I'm not sure how
> best to extract this information from git. 'git-rerere' doesn't seem to
> do anythig, even with:
>
> $ git-config --list
> rerere.enabled=1
"git rerere" works behind the scenes to fix up merge conflicts that you
have fixed once before. All it does is record the diff of conflicted
files after the merge fails and then the new versions of those files when
you do the next commit. I know of no way to get any useful information
out of it.
The git show below should, however, be sufficient and looks just like
what I did on Friday.
I have a plan for getting rid of these - I will start on it today or
tomorrow.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Resolved merge conflicts in next-creds
2008-08-11 0:16 ` Stephen Rothwell
@ 2008-08-11 5:35 ` Stephen Rothwell
2008-08-11 21:53 ` James Morris
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2008-08-11 5:35 UTC (permalink / raw)
To: James Morris; +Cc: David Howells, linux-kernel, David S. Miller, Steve French
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
Hi David, James,
On Mon, 11 Aug 2008 10:16:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I have a plan for getting rid of these - I will start on it today or
> tomorrow.
As a start, can you create a patch (or patches) that does just the
include/linux/creds.h part of commits
785af0f385cd424d4b40908bf0e467df3dc05434 ("CRED: Change current->fs[ug]id
to current_fs[ug]id()") and f4d399d40debd14b22967153294b94087cbcf789
("CRED: Wrap most current->e?[ug]id and some task->e?[ug]id") and send
that to Linus explaining to him the reason we want these in 2.6.27
(Something like "The introduction of the credentials API in 2.6.28
requires the abstracting of access to some fields in the task structure.
This change introduces trivial noop version of the desired accessors so
that other subsystems can start to be converted over."). This
explanation should go in the commit message.
After he has put those patch(es) in, you could break up the rest of those
two commits by subsystem/arc/driver (or something) and ask the
appropriate maintainers to apply them and send them to Linus (with a
similar explanation) (or just ask them to ACK such patches so you can
send them upstream).
Hopefully this way ww will avoid a lot of the merge pain during the next
merge window and the other subsystems can continue on in their
development.
How does that sound?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Resolved merge conflicts in next-creds
2008-08-11 5:35 ` Stephen Rothwell
@ 2008-08-11 21:53 ` James Morris
2008-08-11 23:36 ` Stephen Rothwell
0 siblings, 1 reply; 9+ messages in thread
From: James Morris @ 2008-08-11 21:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Howells, linux-kernel, David S. Miller, Steve French
On Mon, 11 Aug 2008, Stephen Rothwell wrote:
> Hi David, James,
>
> On Mon, 11 Aug 2008 10:16:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I have a plan for getting rid of these - I will start on it today or
> > tomorrow.
>
> As a start, can you create a patch (or patches) that does just the
> include/linux/creds.h part of commits
> 785af0f385cd424d4b40908bf0e467df3dc05434 ("CRED: Change current->fs[ug]id
> to current_fs[ug]id()") and f4d399d40debd14b22967153294b94087cbcf789
> ("CRED: Wrap most current->e?[ug]id and some task->e?[ug]id") and send
> that to Linus explaining to him the reason we want these in 2.6.27
> (Something like "The introduction of the credentials API in 2.6.28
> requires the abstracting of access to some fields in the task structure.
> This change introduces trivial noop version of the desired accessors so
> that other subsystems can start to be converted over."). This
> explanation should go in the commit message.
>
> After he has put those patch(es) in, you could break up the rest of those
> two commits by subsystem/arc/driver (or something) and ask the
> appropriate maintainers to apply them and send them to Linus (with a
> similar explanation) (or just ask them to ACK such patches so you can
> send them upstream).
>
> Hopefully this way ww will avoid a lot of the merge pain during the next
> merge window and the other subsystems can continue on in their
> development.
>
> How does that sound?
We have tried this approach thus far without success, although perhaps now
the code has been in linux-next and you've come to the same conclusion, we
could try again.
David, if you want to make a minimal API-only patch set, I'll can stage it
and push to Linus.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Resolved merge conflicts in next-creds
2008-08-11 21:53 ` James Morris
@ 2008-08-11 23:36 ` Stephen Rothwell
2008-08-12 9:27 ` David Howells
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2008-08-11 23:36 UTC (permalink / raw)
To: James Morris; +Cc: David Howells, linux-kernel, David S. Miller, Steve French
[-- Attachment #1: Type: text/plain, Size: 926 bytes --]
Hi James, David,
On Tue, 12 Aug 2008 07:53:40 +1000 (EST) James Morris <jmorris@namei.org> wrote:
>
> We have tried this approach thus far without success, although perhaps now
> the code has been in linux-next and you've come to the same conclusion, we
> could try again.
>
> David, if you want to make a minimal API-only patch set, I'll can stage it
> and push to Linus.
The important thing (and what is different in what I have proposed) is
that what you are asking Linus to take here has zero impact (i.e. you just
add a header file that noone uses and whose contents are clearly noops)
and then it is very obvious that when people start to use it, the changes
really cannot introduce a regression.
Of course, Linus has to be convinced that the long term API change is
sensible as well.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Resolved merge conflicts in next-creds
2008-08-11 23:36 ` Stephen Rothwell
@ 2008-08-12 9:27 ` David Howells
2008-08-12 11:19 ` Stephen Rothwell
0 siblings, 1 reply; 9+ messages in thread
From: David Howells @ 2008-08-12 9:27 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dhowells, James Morris, linux-kernel, David S. Miller,
Steve French
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> The important thing (and what is different in what I have proposed) is
> that what you are asking Linus to take here has zero impact (i.e. you just
> add a header file that noone uses and whose contents are clearly noops)
> and then it is very obvious that when people start to use it, the changes
> really cannot introduce a regression.
Actually, you do have to modify XFS too. It declares current_fsuid(),
current_fsgid() and struct cred within itself. The first two just require
some simple renames, and the third just requires using my struct cred instead
when it appears.
David
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Resolved merge conflicts in next-creds
2008-08-12 9:27 ` David Howells
@ 2008-08-12 11:19 ` Stephen Rothwell
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2008-08-12 11:19 UTC (permalink / raw)
To: David Howells; +Cc: James Morris, linux-kernel, David S. Miller, Steve French
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
Hi David,
On Tue, 12 Aug 2008 10:27:08 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > The important thing (and what is different in what I have proposed) is
> > that what you are asking Linus to take here has zero impact (i.e. you just
> > add a header file that noone uses and whose contents are clearly noops)
> > and then it is very obvious that when people start to use it, the changes
> > really cannot introduce a regression.
>
> Actually, you do have to modify XFS too. It declares current_fsuid(),
> current_fsgid() and struct cred within itself. The first two just require
> some simple renames, and the third just requires using my struct cred instead
> when it appears.
One step at a time ... the rename is clearly necessary, but adding
"struct cred" can wait. We may not be able to get all the conflicts
solved by adding stuff to Linus' tree early. My aim is just to reduce my
pain level. :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Resolved merge conflicts in next-creds
2008-08-10 23:57 Resolved merge conflicts in next-creds James Morris
2008-08-11 0:16 ` Stephen Rothwell
@ 2008-08-11 14:51 ` Steven French
2008-08-11 23:39 ` Stephen Rothwell
1 sibling, 1 reply; 9+ messages in thread
From: Steven French @ 2008-08-11 14:51 UTC (permalink / raw)
To: James Morris
Cc: David S. Miller, David Howells, linux-kernel, Stephen Rothwell
These (cifs) changes should be in Linus's mainline now so should be easier
to merge your patch now.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
James Morris <jmorris@namei.org>
08/10/2008 06:57 PM
To
David Howells <dhowells@redhat.com>
cc
Stephen Rothwell <sfr@canb.auug.org.au>, linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>, Steven French/Austin/IBM@IBMUS
Subject
Resolved merge conflicts in next-creds
I manually resolved the following conflicts in
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next-creds
when merging with latest Linus. (This branch holds the creds API changes
from David Howells and is being pulled into linux-next).
commit 293f28d5b02efe4504d5976f6f5889458ed56539
Merge: ea40dc0... 796aade...
Author: James Morris <jmorris@namei.org>
Date: Mon Aug 11 09:22:10 2008 +1000
Merge branch 'master' into next-creds
Conflicts:
arch/sparc64/kernel/sys_sparc32.c
fs/cifs/dir.c
fs/cifs/inode.c
---
The Sparc conflicts were from a bunch of code which Adrian Bunk removed in
ea771bd51c3b9b9683860515d93e6155a345fa2f, and should not be able to cause
problems.
The CIFS conflicts were collisions with API changes. I'm not sure how
best to extract this information from git. 'git-rerere' doesn't seem to
do anythig, even with:
$ git-config --list
rerere.enabled=1
A git-show on the merge ID produces the following:
commit 293f28d5b02efe4504d5976f6f5889458ed56539
Merge: ea40dc0... 796aade...
Author: James Morris <jmorris@namei.org>
Date: Mon Aug 11 09:22:10 2008 +1000
Merge branch 'master' into next-creds
Conflicts:
arch/sparc64/kernel/sys_sparc32.c
fs/cifs/dir.c
fs/cifs/inode.c
Signed-off-by: James Morris <jmorris@namei.org>
diff --cc fs/cifs/dir.c
index a2d4a2b,e962e75..2f02c52
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@@ -226,23 -226,28 +226,28 @@@ cifs_create(struct inode *inode, struc
/* If Open reported that we actually
created a file
then we now have to set the mode if
possible */
if ((pTcon->unix_ext) && (oplock &
CIFS_CREATE_ACTION)) {
+ struct
cifs_unix_set_info_args args = {
+ .mode =
mode,
+ .ctime =
NO_CHANGE_64,
+ .atime =
NO_CHANGE_64,
+ .mtime =
NO_CHANGE_64,
+ .device
= 0,
+ };
+
if
(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SET_UID) {
- CIFSSMBUnixSetPerms(xid, pTcon, full_path, mode,
- (__u64)current_fsuid(),
- (__u64)current_fsgid(),
- 0 /* dev */,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
- args.uid
= (__u64) current->fsuid;
++ args.uid
= (__u64) current_fsuid();
+ if
(inode->i_mode & S_ISGID)
+ args.gid = (__u64) inode->i_gid;
+ else
- args.gid = (__u64) current->fsgid;
++ args.gid = (__u64) current_fsgid();
} else {
- CIFSSMBUnixSetPerms(xid, pTcon, full_path, mode,
- (__u64)-1,
- (__u64)-1,
- 0 /* dev */,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
+ args.uid
= NO_CHANGE_64;
+ args.gid
= NO_CHANGE_64;
}
+ CIFSSMBUnixSetInfo(xid,
pTcon, full_path, &args,
+ cifs_sb->local_nls,
+ cifs_sb->mnt_cifs_flags &
+ CIFS_MOUNT_MAP_SPECIAL_CHR);
} else {
/* BB implement mode
setting via Windows security
descriptors e.g. */
@@@ -266,8 -271,13 +271,13 @@@
if
((oplock & CIFS_CREATE_ACTION) &&
(cifs_sb->mnt_cifs_flags &
CIFS_MOUNT_SET_UID)) {
- newinode->i_uid = current->fsuid;
+ newinode->i_uid = current_fsuid();
- newinode->i_gid = current_fsgid();
+ if (inode->i_mode & S_ISGID)
+ newinode->i_gid =
+ inode->i_gid;
+ else
+ newinode->i_gid =
- current->fsgid;
++ current_fsgid();
}
}
}
@@@ -357,21 -367,24 +367,24 @@@ int cifs_mknod(struct inode *inode, str
if (full_path == NULL)
rc = -ENOMEM;
else if (pTcon->unix_ext) {
- mode &= ~current->fs->umask;
+ struct cifs_unix_set_info_args args = {
+ .mode = mode &
~current->fs->umask,
+ .ctime =
NO_CHANGE_64,
+ .atime =
NO_CHANGE_64,
+ .mtime =
NO_CHANGE_64,
+ .device =
device_number,
+ };
if (cifs_sb->mnt_cifs_flags &
CIFS_MOUNT_SET_UID) {
- rc =
CIFSSMBUnixSetPerms(xid, pTcon, full_path,
- mode,
(__u64)current_fsuid(),
- (__u64)current_fsgid(),
- device_number, cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
- args.uid = (__u64)
current->fsuid;
- args.gid = (__u64)
current->fsgid;
++ args.uid = (__u64)
current_fsuid();
++ args.gid = (__u64)
current_fsgid();
} else {
- rc =
CIFSSMBUnixSetPerms(xid, pTcon,
- full_path, mode, (__u64)-1, (__u64)-1,
- device_number, cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
+ args.uid = NO_CHANGE_64;
+ args.gid = NO_CHANGE_64;
}
+ rc = CIFSSMBUnixSetInfo(xid, pTcon,
full_path,
+ &args,
cifs_sb->local_nls,
+ cifs_sb->mnt_cifs_flags &
+ CIFS_MOUNT_MAP_SPECIAL_CHR);
if (!rc) {
rc =
cifs_get_inode_info_unix(&newinode, full_path,
diff --cc fs/cifs/inode.c
index 4857f15,28a2209..e18ce20
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@@ -984,25 -985,34 +985,34 @@@ mkdir_get_info
* failed to get it from the server or
was set bogus */
if ((direntry->d_inode) &&
(direntry->d_inode->i_nlink < 2))
direntry->d_inode->i_nlink = 2;
+
mode &= ~current->fs->umask;
+ /* must turn on setgid bit if parent dir
has it */
+ if (inode->i_mode & S_ISGID)
+ mode |= S_ISGID;
+
if (pTcon->unix_ext) {
+ struct
cifs_unix_set_info_args args = {
+ .mode =
mode,
+ .ctime =
NO_CHANGE_64,
+ .atime =
NO_CHANGE_64,
+ .mtime =
NO_CHANGE_64,
+ .device
= 0,
+ };
if
(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SET_UID) {
- CIFSSMBUnixSetPerms(xid, pTcon, full_path,
- mode,
- (__u64)current_fsuid(),
- (__u64)current_fsgid(),
- 0 /* dev_t */,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
- args.uid
= (__u64)current->fsuid;
++ args.uid
= (__u64)current_fsuid();
+ if
(inode->i_mode & S_ISGID)
+ args.gid = (__u64)inode->i_gid;
+ else
- args.gid = (__u64)current->fsgid;
++ args.gid = (__u64)current_fsgid();
} else {
- CIFSSMBUnixSetPerms(xid, pTcon, full_path,
- mode, (__u64)-1,
- (__u64)-1, 0 /* dev_t */,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
+ args.uid
= NO_CHANGE_64;
+ args.gid
= NO_CHANGE_64;
}
+ CIFSSMBUnixSetInfo(xid,
pTcon, full_path, &args,
+ cifs_sb->local_nls,
+ cifs_sb->mnt_cifs_flags &
+ CIFS_MOUNT_MAP_SPECIAL_CHR);
} else {
if
(!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_CIFS_ACL) &&
(mode & S_IWUGO) ==
0) {
@@@ -1023,9 -1033,13 +1033,13 @@@
if
(cifs_sb->mnt_cifs_flags &
CIFS_MOUNT_SET_UID) {
direntry->d_inode->i_uid =
- current->fsuid;
+ current_fsuid();
- direntry->d_inode->i_gid =
- current_fsgid();
+ if (inode->i_mode & S_ISGID)
+ direntry->d_inode->i_gid =
+ inode->i_gid;
+ else
+ direntry->d_inode->i_gid =
- current->fsgid;
++ current_fsgid();
}
}
}
----
The code compiles ok -- let me know if anything seems wrong.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Resolved merge conflicts in next-creds
2008-08-11 14:51 ` Steven French
@ 2008-08-11 23:39 ` Stephen Rothwell
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2008-08-11 23:39 UTC (permalink / raw)
To: Steven French; +Cc: James Morris, David S. Miller, David Howells, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Hi Steve,
On Mon, 11 Aug 2008 09:51:28 -0500 Steven French <sfrench@us.ibm.com> wrote:
>
> These (cifs) changes should be in Linus's mainline now so should be easier
> to merge your patch now.
Yeah, the conflicts were no longer in yesterday's linux-next merge.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-08-12 11:19 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-10 23:57 Resolved merge conflicts in next-creds James Morris
2008-08-11 0:16 ` Stephen Rothwell
2008-08-11 5:35 ` Stephen Rothwell
2008-08-11 21:53 ` James Morris
2008-08-11 23:36 ` Stephen Rothwell
2008-08-12 9:27 ` David Howells
2008-08-12 11:19 ` Stephen Rothwell
2008-08-11 14:51 ` Steven French
2008-08-11 23:39 ` Stephen Rothwell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.