It is not possible to set capabilities on large file (>2Gb ?)

Thanks for taking the time to submit this bug and helping to make Ubuntu better.

What is the filesystem of your /tmp? Please provide output of

df -h /tmp
mount

Filesystem is ext4.

$ df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/sda6 207G 26G 171G 14% /

$ mount
/dev/sda6 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

I can't reproduce this. Can you run it through strace and upload the
result?

Yes, sure.

Also, I am using linux kernel with PAE support, because I have 8Gb of RAM and want it all available on my 32-bit Ubuntu installation:
ii linux-generic-pae 2.6.32.29.35

# strace setcap 'cap_net_bind_service=+ep' /tmp/prog.x
execve("/sbin/setcap", ["setcap", "cap_net_bind_service=+ep", "/tmp/prog.x"], [/* 30 vars */]) = 0
brk(0) = 0x92e3000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7749000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=59373, ...}) = 0
mmap2(NULL, 59373, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb773a000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libcap.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \17\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=13852, ...}) = 0
mmap2(NULL, 16688, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7735000
mmap2(0xb7738000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7738000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000m\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1405508, ...}) = 0
mmap2(NULL, 1415592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75db000
mprotect(0xb772e000, 4096, PROT_NONE) = 0
mmap2(0xb772f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153) = 0xb772f000
mmap2(0xb7732000, 10664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7732000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libattr.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\r\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=17860, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75da000
mmap2(NULL, 20588, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75d4000
mmap2(0xb75d8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0xb75d8000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75d3000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75d36c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb75d8000, 4096, PROT_READ) = 0
mprotect(0xb772f000, 8192, PROT_READ) = 0
mprotect(0xb7738000, 4096, PROT_READ) = 0
mprotect(0x804a000, 4096, PROT_READ) = 0
mprotect(0xb7767000, 4096, PROT_READ) = 0
munmap(0xb773a000, 59373) = 0
brk(0) =...

Just checked the source code of setcap and found that it does not support large files.
Consider the following code in cap_file.c/cap_set_file:
...
    struct stat buf;

    if (lstat(filename, &buf) != 0) {
 _cap_debug("unable to stat file [%s]", filename);
 return -1;
    }
...

If it is built on 32-bit linux, this code will not work for files large than 2Gb, because lstat() uses stat structure which represents size of file as off_t type.
As a workaround I suppose _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64 can be defined during compilation.

I have tried to recompile libcap2 with compile-time flags for large files and it works for me.
Diff is attached.

# ./setcap 'cap_net_bind_service=+ep' /tmp/prog.x
# ./getcap /tmp/prog.x
/tmp/prog.x = cap_net_bind_service+ep

Thanks for the patch, Mikhail. I will see if the upstream maintainer is willing to take this patch.

Marking this high priority because there is no workaround in capabilities-only mode.

Hi Andrew,

would you be willing to take this patch from Mikhail Kulinich
(posted at https://bugs.launchpad.net/ubuntu/+source/libcap2/+bug/794202)?
upstream?

thanks,
-serge

diff --git a/Make.Rules b/Make.Rules
index 2563e82..b99b752 100644
--- a/Make.Rules
+++ b/Make.Rules
@@ -48,7 +48,7 @@ KERNEL_HEADERS := $(topdir)/libcap/include
 IPATH += -fPIC -I$(topdir)/libcap/include -I$(KERNEL_HEADERS)

 CC := gcc
-CFLAGS := -O2
+CFLAGS := -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
 BUILD_CC := $(CC)
 BUILD_CFLAGS := $(CFLAGS) $(IPATH)
 AR := ar

Serge, I am not sure that patch is correct for all cases (GCC versions, Libc etc).
From my point of view, all system calls/data structures for working with FS should be replaced by *64 analogs if available.

Quoting Mikhail Kulinich (<email address hidden>):
> Serge, I am not sure that patch is correct for all cases (GCC versions, Libc etc).
> >From my point of view, all system calls/data structures for working with FS should be replaced by *64 analogs if available.

I'm going to be out for a bit. If you come up with a better patch, please do forward it to the upstream maintainer.

Note that I *am* curious about what goes into your >2G executable :)

Hi,

Unfortunately, I am not able to test my changes in different environments, but it works at least at Ubuntu 10.04 x86.
Also, I found a script with tests inside libcap2 sources and all of them are passed.

So, when the fix can be expected in Ubuntu repository for regular updates?

Serge, such a big executable is a hard work of dozen designers during last 15 years.

For the moment, it is much easier/cheaper to fix libcap2 than refactor this application. :-(

I believe your patch is applied upstream. We need to post a debian bug to have it pulled into the debian package, then it will auto-sync into Ubuntu. I will be back on Monday, and can file the debian bug then, or, if you prefer, please go ahead and post the bug yourself and place the debian bug # here.

This was actually fixed when libcap2 1:2.21-2..1:2.22-1 were copied from Debian into Ubuntu:
libcap2 (1:2.21-2) unstable; urgency=low

  [ Serge Hallyn ]
  * 0002-support-getting-setting-capabilities-on-large-files.patch: patch from
    upstream to enable setting capabilities on large files.
    (Closes: #631134)

  [ Torsten Werner ]
  * Move package to alioth's collab-maint project.
    * Use git instead of svn.
    * Update Vcs-* headers in debian/control.

  [ Zhi Li ]
  * Modify long description in libcap2-bin/debian/control, remove those files that were not generated.
    (Closes: #620345)

 -- Torsten Werner <email address hidden> Mon, 11 Jul 2011 22:11:41 +0200

Fixed in oneiric and precise.